In most web projects, we do both client-side and server-side form validation.
A major part of form validation is error prompt,
the client-side and server-side form validation library probably have implemented this for us,
but the error prompt looks different.
How can I design a consistent error prompt for such a system?
Thanks in advance.
The server-side validation should not be concerning itself with presenting errors to the user. It should simply return messages with details relevant to the hurled exception. The client-side exception handler should intercepted these messages, interpret them if necsseary and display the message to the user.
Well, that's the general principle. If you want specific advice you will need to edit your question to more details regarding your architecture.
Related
I have a website where i have implemented google recaptcha, however it does not have server side validation. I want to know if google mandates server side validation. I have search through web but did not found anything on this.
Any supporting document/link on this is appreciated.
Google does not force to perform the server-side validation but this is a necessary step if you want to ensure you are protected.
If you implement a client-side only validation it means there is still a request to your backend which does not enforce the captcha validation, and potentially can be exploited.
Here is an example where at server-side the validation is executed before the action (post comment, save user details, etc..) is performed.
I have created a backend code in spring-boot for an android app.
My question, is there any rule for distinguishing between the validations at backend side or at frontend side?
For example- for user creation blank fields should be only checked at the frontend side but for testing backend services alone is it okay to have validations on the backend side.
If we just do validations at the frontend side then the problem arises when we test backend services alone.
As general rule, data sent from the client cannot be trusted. E.g. even if the client validated a field is not null, you should assume that field was not validated at all.
You should implement similar validation logic on the backend as well.
Here's the starting point for implementing validation with Spring, based on JSR-303.
It's not only "ok" to have validation on the backend but it's required. As #hovanessyan mentioned, you can never trust the data from the client. Never.
As a rule of thumb, APIs need to be bullet proof. All the edge cases (null-safety, type-safety, min/max, custom validations) should be covered and tested. There's nothing worse than an API responding with a 500.
Lots of devs noticed that there's a bit of validation logic duplication between frontend and backend and this is one of the reasons technologies like Node.js became so popular - you could in theory share the validations.
Also, don't be discouraged by having to duplicate your validation logic. It's tedious but necessary.
I was reading about AJAX on IBM's website. Here is what it said,
If the application fails to communicate, it might leave users unsure
about what is actually happening. If they click a Form Submit button
and nothing happens, they might assume the Web site is broken. If the
application fails to communicate that an error occurred, users
generally assume that their action succeeded. This assumption can lead
to extreme frustration if the reality is that the action did not
succeed, especially if a user has just spent a long time working on
the content of the form. If the application informs users when there
is an error or timeout, at least the user has an opportunity to copy
and paste the data and save it locally, thus avoiding one of the worst
possible user experiences.
Now this problem can also occur while using JavaScript or HTML. Why does the author refer AJAX as Ajax can ruin your site?
It's dangerous because when using AJAX to process form submissions, you are changing the usual user experience. When a user clicks on the submit button, you are in charge of informing them that something is actually happening (Placing a loading gif for example)
If the request fails, it's also your responsibility to inform the user that it failed, and perhaps offer a solution and information. If you don't, the user will be clueless as to what happened, they won't know if their form submission really did something, if the information they sent has been saved... etc
AJAX is "dangerous" because it completely relies on the developer to work fine.
If the network connection is lost for example, the AJAX request will fail and many developers forget to use a timer to check for this kind of thing, thus the user will be left alone wondering what actually happened. If the request did make it to the server, but the answer didn't return, the action might have been done (e.g. registering a new user), but the user won't know.
Because you can be more sure that your local JavaScript code will get executed as you intended. However, as Ajax may be affected by network congestion and other external problems, you can not be as sure. Unless proper precautions are taken (like checking for a timeout), certain functions might not be called at all, leaving the user confused.
Static javascript code should have the same outcome everytime it is executed (this really depends on the code, but we're talking about general/simple javascripts).
AJAX on the other hand is always subject to external factors affecting it's execution (internet connectivity problems / timeouts / server load, etc).
I have seen many AJAX scripts not handling timeouts or failed connection/reading attempts leaving the "loading bar" (if there is one) hanging
I have to perform some client side validation.
The error messages should need to appear based on client language.
Currently i have hardcoded the messages in the javascript code.
How do i access the property files from javascript?
Is there a better way to achieve this?
You can do that using internationalization but it's on server side. First of all identify the when you are processing the request identify the user language and display the appropriate message. refer the following example. http://www.mkyong.com/struts2/struts-2-i18n-or-localization-example/
I don't quite understand why client side validation is a potential security risk or more of a security risk than server side validation? Can someone give me some scenarios?
Ideally you'd do both client and server side and never one or the other. If we take at look at these 3 scenarios, both is the only secure, user-friendly way to do it:
Client Side Only: As mentioned, it doesn't take much to get around these validations if somebody wants to send malformed data to your server (such as SQL injection). NoScript won't run the javascript validation code, and some browsers allow the user to actively change all loaded javascript and html, so a user could unhook the validation javascript from the controls.
Server Side Only: This one is more secure than Client-only by a long shot, but cuts back on user friendliness. They have to send their form to the server, have it validated and receive the error page back saying a particular field was invalid. What's annoying is that if any of those fields were password fields, their values are not repopulated by default. For example, lets say the user didn't input a phone number correctly in an account creation form. When the server spits back the page about how the phone number is wrong, the user will see that, correct the phone number and hit submit again, just to receive another error page about not having entered a password (and entering it again in it's second textbox) even though that wasn't the initial problem.
Client and Server Side: You get the security of the server side validation, something the user will be hard-pressed to interfere with, and the user friendliness of input validation without having to submit the page (whether you validate through purely local javascript or AJAX).
If you absolutely had to pick one, server side would be the way to go. But you shouldn't ever have to pick one or the other.
Using various tools, such as Fiddler, Noscript, Web Developer, etc., I could disable the client-side javascript validation, and modify the data being sent to your server. Depending on the type of data and what the server does with it, one could initiate a SQL injection attack, attempt to compromise the server security, or simply store bogus data.
A lightweight example: Say you have client-side validation to ensure that a zip code is 5 digits or 5+4 digits. If I disable the client-side script, I could leave my 24-digit value in place. If your server doesn't further check the value, and the database is capable of storing all 24 digits, then I have saved the bogus data.
If you do validation only in client-side, someone may disable javascript (or change the js code, with firebug, for example). So, all validations made in js would be useless and user can insert invalid data in your system.
I assume you're talking about a web scenario?
If you're doing client side validation with Javascript, what happens if the user has Javascript disabled? Then they can submit data to the server that has not been validated.
If they were sneaky, they could even post data directly to your server (bypassing your page completely).
If you do server side validation, in addition to or instead of client side validation, then you have an additional opportunity to defend against these scenarios.
Actually, there is a huge security advantage to client-side validation (in combination with server-side validation). If you validate carefully on the client, then ALL the traffic coming into the server should be clean. Except for the attackers. That makes it possible to do much better server-side attack detection. In the big scheme of things, that's probably the most important thing that you could possibly do to protect your applications. See the OWASP ESAPI IntrusionDetector or the OWASP AppSensor for more on this.
Oh, and obviously if the attack starts and finishes in the client, like DOM-based XSS, then you're going to have to validate and encode on the client-side.