4 ms·

Speaking with my security hat on: This is a really nice library, but you also do the same validations server side right?

by st3fan 14y ago

joeblau 14y ago
I didn't write this, but I would say yes. You would have to check twice just incase someone tried to POST directly to your URI bipassing your form page.
why-el 14y ago
Great question. I would usually prefer server side validation, and with the nice integration that Rails provides between form errors and validations on the model, I am not sure how I can use this. Does anybody who uses a Rails stack combine both server side and client side validations?
- mjs7231 14y ago
  From a Django background which also provides form errors very easily, it seems at first glance that this would not be needed (and it technically isn't). However, it's often nice to the user to let them know of silly mistakes like passwords not matching or invalid emails before they hit submit and get bombarded with everything at once. Javascript validation provides convenience, not security.
- rquantz 14y ago
  I usually use both for anything public facing. Server side is for security, client side is for UX. keeping it dry is a problem, obviously, but you don't always want the same validations server- and client-side.
- rpackard 14y ago
  Adding client side validations offloads some work from your servers. It could reduce the number of total requests that hit your server and overall increase your speed. This may be premature optimization for a lot of cases but for form heavy apps this could be a useful optimization. Also saving a round trip to the server can make the UX seem snappier and overall give a better user experience.
- lnanek2 14y ago
  I thought it was standard to have both. Server side validation to keep bad data out and client side validation to provide a nicer UX for the user than a complete page reload and them searching around for what went wrong.
  - dinkumthinkum 14y ago
    Yeah, for some reason people always bring up server side validation on these kinds of posts about client side validation ... doesn't server side validation go without saying?
    - vidarh 14y ago
      You'd think it goes without saying, but I've seen enough code where people didn't. Including code where the client side JS validation was pretty much a guide to hacking the site (trying in vain to protect against SQL injection attacks in one of the most horrific examples, where the SQL injection checks essentially told you exactly what to try to post directly to their server...)
Tloewald 14y ago
Client side and server side validations need (should!) not be the same — i'd make serverside validation stricter. Client side is for eliminating honest mistakes not preflighting exploits.
- djbender 14y ago
  Could you give an off the top of your head example?
  - cjp 14y ago
    An honest mistake: Your form has 3 required fields but the user only filled out 2. This shouldn't require a trip to the server. A hack attempt may be a direct POST circumventing any client side checks.
  - saidajigumi 14y ago
    The web is brimming with examples, here are a few: 1) You can only do a mod 10 check (aka the Luhn algorithm) for client-side credit card validation. Beyond that, you'll need to hit a server to run a CC authorization. 2) In the email check one commenter criticized re: correctly parsing "m@apple.comm", there are practical limits. Syntactically, that's a correct email address. To that you could add content checks such as validating against known TLDs. Then you've got to ensure that your whitelist is correct and that it remains up-to-date as the TLD namespace changes. As for evaluating the registered domain name client-side, ehhhh.. maybe not. At some point you've just got to go do the DNS lookup and send an email to find out if it's going to work. In general there are classes of problems for which some lightweight validation is practical on the client, but full validation requires extended information or transactions that are im{practical,possible} on the client.
    - spc476 14y ago
      About the only way to validate an email address (short of sending it an email) is to parse the email address using BNF from RFC-2822 (I use LPeg to do that) and if that passes, then do a DNS MX lookup on the domain; if that fails, then do a DNS A lookup on the domain. That will at least tell you that an email can be delivered, not that it will be delivered and short of sending email, that's about the best you can do.
guillaumepotier 14y ago
Parsley's aim is to have think about validation just once back end and seamlessly do the same front end with no extra work. But yes that do not exempt you to validate backend ;)
jmadsen 14y ago
At the risk of spamming (since it's my own blog), anyone still wondering about that question should read this or similar tuts - explaining that question and all the basic mistakes people make in validation & security http://www.codebyjeff.com/blog/2012/12/web-form-security-avoiding-common-mistakes http://www.codebyjeff.com/blog/2012/12/web-form-security-avo... Nothing to do with sexy xss & the like - just some simple foundation points when setting up your server side procesing

Speaking with my security hat on: This is a really nice library, but you also do the same validations server side right?

by st3fan 14y ago

Speaking with my security hat on: This is a really nice library, but you also do the same validations server side right?

joeblau 14y ago

I didn't write this, but I would say yes. You would have to check twice just incase someone tried to POST directly to your URI bipassing your form page.

why-el 14y ago

Great question. I would usually prefer server side validation, and with the nice integration that Rails provides between form errors and validations on the model, I am not sure how I can use this. Does anybody who uses a Rails stack combine both server side and client side validations?

mjs7231 14y ago
From a Django background which also provides form errors very easily, it seems at first glance that this would not be needed (and it technically isn't). However, it's often nice to the user to let them know of silly mistakes like passwords not matching or invalid emails before they hit submit and get bombarded with everything at once. Javascript validation provides convenience, not security.
rquantz 14y ago
I usually use both for anything public facing. Server side is for security, client side is for UX. keeping it dry is a problem, obviously, but you don't always want the same validations server- and client-side.
rpackard 14y ago
Adding client side validations offloads some work from your servers. It could reduce the number of total requests that hit your server and overall increase your speed. This may be premature optimization for a lot of cases but for form heavy apps this could be a useful optimization. Also saving a round trip to the server can make the UX seem snappier and overall give a better user experience.
lnanek2 14y ago
I thought it was standard to have both. Server side validation to keep bad data out and client side validation to provide a nicer UX for the user than a complete page reload and them searching around for what went wrong.
- dinkumthinkum 14y ago
  Yeah, for some reason people always bring up server side validation on these kinds of posts about client side validation ... doesn't server side validation go without saying?
  - vidarh 14y ago
    You'd think it goes without saying, but I've seen enough code where people didn't. Including code where the client side JS validation was pretty much a guide to hacking the site (trying in vain to protect against SQL injection attacks in one of the most horrific examples, where the SQL injection checks essentially told you exactly what to try to post directly to their server...)

Tloewald 14y ago

Client side and server side validations need (should!) not be the same — i'd make serverside validation stricter. Client side is for eliminating honest mistakes not preflighting exploits.

djbender 14y ago
Could you give an off the top of your head example?
- cjp 14y ago
  An honest mistake: Your form has 3 required fields but the user only filled out 2. This shouldn't require a trip to the server. A hack attempt may be a direct POST circumventing any client side checks.
- saidajigumi 14y ago
  The web is brimming with examples, here are a few: 1) You can only do a mod 10 check (aka the Luhn algorithm) for client-side credit card validation. Beyond that, you'll need to hit a server to run a CC authorization. 2) In the email check one commenter criticized re: correctly parsing "m@apple.comm", there are practical limits. Syntactically, that's a correct email address. To that you could add content checks such as validating against known TLDs. Then you've got to ensure that your whitelist is correct and that it remains up-to-date as the TLD namespace changes. As for evaluating the registered domain name client-side, ehhhh.. maybe not. At some point you've just got to go do the DNS lookup and send an email to find out if it's going to work. In general there are classes of problems for which some lightweight validation is practical on the client, but full validation requires extended information or transactions that are im{practical,possible} on the client.
  - spc476 14y ago
    About the only way to validate an email address (short of sending it an email) is to parse the email address using BNF from RFC-2822 (I use LPeg to do that) and if that passes, then do a DNS MX lookup on the domain; if that fails, then do a DNS A lookup on the domain. That will at least tell you that an email can be delivered, not that it will be delivered and short of sending email, that's about the best you can do.

guillaumepotier 14y ago

Parsley's aim is to have think about validation just once back end and seamlessly do the same front end with no extra work. But yes that do not exempt you to validate backend ;)

jmadsen 14y ago

At the risk of spamming (since it's my own blog), anyone still wondering about that question should read this or similar tuts - explaining that question and all the basic mistakes people make in validation & security http://www.codebyjeff.com/blog/2012/12/web-form-security-avoiding-common-mistakes http://www.codebyjeff.com/blog/2012/12/web-form-security-avo... Nothing to do with sexy xss & the like - just some simple foundation points when setting up your server side procesing