I was talking to a co-worker and we had a discussion on client side validation.
Which validation method is better (javascript/asp.net validation)?
I know when javascript is disabled on the browser then validation would be disabled but with asp.net validation control, you can just call the method page.validate() to do validation even though javascript is disabled.
You should always do server-side validation or you risk injection attacks.
JavaScript validation is nice-to-have and prevents unnecessary round-trips to the server, but it can be disabled like you point out.
Use server side validation for data integrity and security. Use client side validation for usability. Server side should always be used. But client side validation should be used as a way to enhance value to users. I make a dumb typo I want the app to be smart enough to catch my mistake. If you expect your users to always do the most unexpected things you will have a good strategy. Although there are many smart people using the web. If you start with the assumption that it mostly just monkeys typing random stuff into the computer then your code and project will be more robust. And when it comes to publicly facing websites and bot nets, the monkey analogy is not that far off. It really is just random stuff entering through your forms.
Do both.
JavaScript gives near immediate results.
ASP.NET validation is the solution for bullet-proofing/fool-proofing/spoof-proofing. It is a must to have.
You have to do server side validation. Imagine your user has js disabled, it could mess up your database. You also risk all kind of injection attacks.
That said, in some cases inline validation is nice because it gives the user an immediate feedback, improving the usability.
Related
I'm using ReCAPTCHA which means that I have to submit the form from JS, not HTML, but HTMLFormElement.submit() doesn't confirm the form is valid first and I have written some checks that I would like to still be effective. The only solutions I see are for writing all the checks in JS (for people wanting custom checks) and ones that use JQuery. None of the solutions seem to have the browser-styled error messages that show below the field which isn't preferable. Is there a simple way to do this or do I have to do something like iterating over all the fields and validate them manually? Preferably, I would also like to run the checks before ReCAPTCHA even generates a score, but I doubt this is possible because of how limited ReCAPTCHA's API seems to be. It's worth noting that I manually validate the values server-side already, as I'm aware it would be easy for people to get round these checks, but I'd like to avoid unnecessary POST requests and be able to use the browser-styled error messages.
First of all, you have too many questions/issues in one post. You're normally expected to try and figure things out on your own as much as you can before asking. Here are some issues I picked up:
Form validation process does not conflict with form submission process.
Whether recaptcha goes before or after the validation is not an important issue, but vast majority of forms where it's used, do it after the validation.
Try to avoid using JQuery since it adds an unneeded dependency. Pure JS is just as powerful.
If you want a nicely styled error message - that's a completely different issue that has no relation to recaptcha or form submission. You now talking about DOM editing and styling.
Running something before recaptcha is a question of timing things rather than limitations of Recaptcha's API. It's completely in your power.
Server-side validation and client-side validation are both needed, but they largely play different roles: client is more for user-friendly error reporting while server is a real validation of user input. It's a good practice to keep them in tight sync. So having BE validation doesn't excuse you from having FE validation.
You don't need additional POST requests for FE validation. Additional communication with the back-end during validation is needed for things that the client can't validate.
Finally, you can do your validation before submitting the payload to the server. I suggest looking at the concept of async: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function
This is to make your form submission after the response from Recaptcha comes and after you're done with your FE validation.
Promises is how it's usually comfortable to work with: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise
I read here that the main reason for using client side validation is:
the user can correct every field before they submit the form
This (sort of) assumes Ajax, but if the client side validation consists purely of Javascript, is there really a point to it anymore? It's easy enough to point out specific mistakes and store form data on refresh from PHP / Django / node.js, so if the client side script isn't pointing out mistakes as the user is making them, does it really make sense both from a UI and developer perspective to take the time to write that bit of code?
Client side validation helps you prevent errors from entering into your server/database and adds a second layer of protection.
As far as Ajax is concerned, you will be sending your data from the client to the server one way or another so if you're using Ajax or not is irrelevant.
From a developer's perspective, even something as simple as checking all the fields for valid data types on form submit is worth the effort. This saves your server from having to process an invalid entry and shifts that load to the user's system. For large scale applications this dramatically increases performance.
From a UI perspective, I understand that incorporating error checking into the form makes it a little bit difficult, but in my opinion this is a minor inconvenience to save you much more hassle of having to clean your database in the long run.
Edit: As Ryan pointed out in his comment to the question, users definitely appreciate feedback without having to wait for it
I have a form users fill out and JavaScript is used to validate the input (e.g. makes sure the password field isn't left blank). Since JavaScript is client side and not compiled anyone can easily mess around with it. Does this mean it's necessary to validate data from the user again on the server? If yes, is there anyways it can be made more efficient since JavaScript (theoretically) already did it?
Yes, it is necessary to validate data on the server because it can be messed with by end users client-side.
If yes, is there anyways it can be made more efficient since JavaScript (theoretically) already did it?
It is already more efficient than having only server-side validation, because you avoid a lot of round-trips for validation by having client-side validation (you only need to submit the data once, and unless validation was incomplete or disabled, it will go through straightaway). Provides a better user experience, too.
You cannot do away with server-side validation (if you care about the data). If the data only ever goes back to the same user and is not shown or used anywhere else (and has no potential to break anything on your system), you could relax this a little. As as extreme example, Dropbox probably does not care what files you upload, so they don't validate if the HTML you upload contains malicious Javascript.
I can disable any javascript on your page just with a click of the mouse. I can even totally bypass an HTML form and send data directly to your server.
For example, if you retrieve data with $_GET I can bypass your form (and the javascript validation) just by messing with the address bar. Don't think that using $_POST would change this: it just a matter of writing an HTTP request.
So, yes... Never trust user input, even if sanitized with javascript.
As somebody posted above, javascript validation can prevent legitimate user errors (thus save the trip the wrong data would have done to your server and then back to the user) but malicious users will still be able to bypass it VERY easily.
short answer: yes and always!
read about PDO, SQL injection, UUID, tokens, MD5, SHA, Cross-site request forgery...You have a whole new world to discover! :) I mean it in a good way. Learn about this and you'll build more secure websites
You always need to keep this in mind: Never trust user input data. Never. So you have to perform extra validating process in server-side.
Yes absolutely. It is still possible for someone to intercept the form and modify values before re-posting to the server.
The user certainly can disable JavaScript. It is also very easy to mess with it as the source code is right there. The user can also run arbitrary JS, making it even easier to mess with your stuff.
Therefore, you should always do server side validation as well. Client side validation should only be used as convenient information for the user. Never trust it as your only security source.
Yes, you MUST validate both in client side and server side.
You must think in terms of progressive enhancement. Think of Javascript as just a layer for enhancement and not a necessity. Because it's always upon the discretion of the user to disable Javascript in their browser, rendering your Javascript code useless.
A plus in client side validation is you're saving roundtrips to the server validating if the username or password is empty which can easily be done in javascript.
Yes, to be safe you will need to add server side validation.
Nothing that is expected to have been done on the client side is guaranteed so you will need to repeat anything that is important.
Additionally there are things that are likely to be evaluated on the server side but not on the client side. Things like checks for SQL injection fall into this category.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
One argument for using both client side validation (JavaScript) and server side validation using a validator is that if the client browser does not support JavaScript or JavaScript has been turned off deliberately, then client side validation is rendered useless.
My question is how good is this argument in practice? In theory it makes sense, but in practice, if JavaScript is disabled in the browser, then most website features will not even work. The user probably cannot even load the page without JavaScript, let alone submit a form.
Client-side validation just avoids the client from going "but I filled this all in and it didn't tell me anything!". It's not actually mandatory, and in reality, client-side validation is a very new thing (read: 5 years old or less). In practice, all it does is prevent your client (with JS enabled) to know whether the form is okay before reloading a page.
If AJAX is in the game, it is different - it allows you to save bandwidth as well as to provide user with feedback before submission.
Finally, if you're building strictly client-side, peer-to-peer exchange apps (think games), you'll want client-side validation to keep the clients from cheating.
Server-side validation is also crucial due to the fact that client-side validation can be completely bypassed by turning off JavaScript. In a way, JS-driven validation is a convenience and an aesthetic/cosmetic improvement and should not be relied upon. Furthermore, it is trivial to edit the source of a page locally in order to disable or bypass even the most complex of JS validation.
What could a user do if you do not server-side validate? Anything, depending on how you use their data. You could be allowing users to drop entire databases (or worse, leak them), modify anything they like (or worse, read anything they like. Directory traversal flaws are extremely common entrance points for naughty people), and elevate their privileges at will. Do you want to run this risk? Not validating user input is like trusting people and not installing locks on your house.
Validation should always be performed server-side - you can never trust client-side validation.
Client-side validation is always in the sense of providing a better User Experience (UX), so the user doesn't have to submit and reload a page simply because a value in a form isn't valid - it makes things more dynamic.
As you don't even need a browser to make requests, independently of your website relying on JS to work properly, you will need server-side validation and sanitize all user input in case you care about not having your databases pwned.
Now it is up to you whether you want to provide an UI with dynamic client-side validation hints or not.
Always protect your inputs on the server. It's not always about users having JavaScript disabled but also that they could break the server.
For example, if a site has a JavaScript max-length check on an <input>, a user can could disable that check, thereby sending more data than your server and/or database is expecting. This could overload the server by a large POST occupying a server thread for a long time, it could expose a weakness in the database for example violating a database constraint potentially exposing details about any persistence information. Worse, if there is no constraint a user might be able to perform injection attacks.
Another example is someone using an external HTTP tool to send requests to your server, completely bypassing any JavaScript. I use the Advanced REST Client for Chrome all the time in development for testing JSON APIs.
Client side validation through JavaScript is just a way of providing a quicker feedback to a person using the site of any information about their interaction with the site. In traditional client-server communication it should not be the only validation for the reasons outlined above.
If a user has disabled javascript is a problem of himself and he decided alone to disable the javascript for a reason... For that, when you making a website you must have always in mind that your web site must be valid for users with and without javascript. The both side validation is needed for a number of reasons, some of them are:
User has disabled javascript
An evil user in purpose has removed the javascript in order to exploit the system
With javascript validation you reducing the data traffic between the website and the client.
And of course with server validation you make sure once for all that the data are correct
It is possible to have a website that is using both javascript and "older" technologies to be valid for every user and every browser.
Client-side validation is a solution for highly interactive forms with on-the-fly field validation, but it will not prevent a ill-intentioned user from injecting and posting invalid formatted data to the server. It is important that your server-side script validates everything the user is doing, otherwise you will expose your site to SQL injection attacks, XSS attacks, users doing stuff they are not supposed to etc.
I use some jquery and JS functions to validate forms and to check for example if that field is empty or password is less than 6 characters, and stuff like that, and I noticed that if someone disabled JS, then these functions would be useless, and no more protection of forms, which can be better made using PHP, so should I avoid them now because this could cause an insult to my website ?
JavaScript is very useful for improving user-interaction, along with reducing the number of requests made on the server; but, as you've pointed out, it can be disabled. To answer your question: No, I wouldn't recommend avoiding the use of JavaScript, but the key is not to rely on it for critical actions, such as validation. You'll want to implement the validation on both the client (JavaScript) and server (PHP) sides. This will ensure that there is no way for the user to completely disable the validation.
In short:
JavaScript = Good
JavaScript Validation = Nice for the user, but not reliable
Server Side Validation = Essential
Side note:
With regards to relying on JavaScript for the overall user interaction, as other answers have suggested, use JavaScript to enhance the overall experience, but don't rely on the user having it turned on. I would recommend a bit of bed time reading of Progressive Enhancement, it's the approach of making something better, with being reliant on it, and can be applied to more than just JavaScript (CSS3 etc).
You should use javascript and jQuery to enhance the functionality of your site. If someone has javascript turned off you should ensure that the site still works, and they can access all areas - even though there may be some things they cannot see, such as transitions and effects.
With regard to validation, you should ALWAYS validate server side. Client side validation is optional, but a very nice feature to improve the user experience for your visitors.
I don't mean this as a complaint, more of an observation.
Web developers often grab Javascript libraries as the latest shiny toys with no thought for the consequences. As a Data Governance person, I'm regularly the bringer of bad news, when we do audits on the data collected, and find users who get past the Javascript validation.
"Go back and start again".
Javascript libraries are great for the presentation of data, but should and must not be relied on for data validation and the integrity of user profiles.
A validation should always happen at
Client Side - using javascript to enhance the user experience.
Server Side - using the preferred server side programming language for security reasons
Service Side - if you are following SOA / Web API as part of defensive programming practice. This can also be at the DB level along with Service layer.
You should not avoid using JS and jQuery in your website, but you should avoid using them for validation purposes or business-logic purposes. These should be done in the back-end of the website, not in the UI level.
You shouldn't really avoid them. What you should do is to implement both client and server validation. Don't rely just on client validation, for the reasons you just mentioned. You should always validate the data when it arrives to server.
Adding client-side validation gives your pages dynamic look and feel. A user does not have to wait for the form to go to server and in case of an error to return back. It is automatically verified without postback.
As I said above, don't rely upon client side validation. Always implement server-side validation also.
Remember my friend, Java script is client side scripting. its purpose to validate form at client side itself so we can avoid overhead...You must use java script at client side. because PHp is server side language. It will take time to reply.
Ha, Server Side validations are equally important. if you want to do that, then you can use server side language. You can check comment below to my post by halfer. Server side validations are important for security and many more purposes.
That is different thing that somebody disabled js. You can check for the same and give proper message to enable.