If a user is submitting a form through my website - does the server side validation have to provide anything more than "error: invalid submission"?
If my client side validation is strong enough (and error reporting good and friendly), and if my server side validation is strong too - does the server side error response have to transmit any useful info to the submitter?
Server side validation is for protection, not guiding the user right?
Server-side validation is still needed for users with Javascript disabled.
You need to decide how much support you want to give them.
You should make sure that the errors do not reveal any implementation details.
Related
As I found, it is possible to manipulate and change Ajax code in browser console by client. For example, Ajax wants to call a method and pass id to controller. As I mentioned above, how we can secure our code from interference by client?
Thank you all
Security must always be implemented on the server side, because anything you do on the client side can be ignored, overstep, modified, etc very easily. In fact, anyone can use software like Postman to make a completely custom HTML request to any server.
Don't ever rely on any client-side software in terms of security for your server. If you want keep your server safe, then make a safe server.
The following is quoted from RFC6455 - WebSocket protocol.
Servers that are not intended to process input from any web page but
only for certain sites SHOULD verify the |Origin| field is an origin
they expect. If the origin indicated is unacceptable to the server,
then it SHOULD respond to the WebSocket handshake with a reply
containing HTTP 403 Forbidden status code.
The |Origin| header field protects from the attack cases when the
untrusted party is typically the author of a JavaScript application
that is executing in the context of the trusted client. The client
itself can contact the server and, via the mechanism of the |Origin|
header field, determine whether to extend those communication
privileges to the JavaScript application. The intent is not to prevent
non-browsers from establishing connections but rather to ensure that
trusted browsers under the control of potentially malicious JavaScript
cannot fake a WebSocket handshake.
I just cannot be sure about what the 2nd paragraph means, especially the italic part. Could anyone explain it a bit? Or maybe an example.
My understanding so far is like this:
If server CAN be sure that requests DO come from Web pages, the ORIGIN header can be used to prevent access from un-welcomed Web pages.
If server CANNOT be sure that requests come from Web pages, the ORIGIN header is merely advisory.
Your understanding seem to be correct, but..
I would rephrase it - you can be sure, that javascript client will send proper origin header. You don't know what will be sent by other clients (and whether the value is correct or not).
This should prevent other pages to connect to "your" web socket endpoints (which is a big deal, imagine injected javascript somewhere on jsfiddle or some frequently visited page), but if you need to make sure that no other client will be able to connect to it, you'll need to introduce some other security measures.
I believe this is meant only as prevention of browser based "data stealing" or "DDoSing", nothing else; you can still do that by using some other client.
At first, I intend to get the validation done on the client side by javascript or jquery, something like that, but then I realize that some malicious users may skip my jsp page, sending data which is not been validated to my servlet. My server end is structured using Spring+SpringMVC+mybatis, is there any way that I can keep the validation on client side, as well as keep my server safe(does spring security help?).Thanks a lot!
You should always validate on the server side.
Validation on the client side is only for convenience of your (honest) users and adds nothing to the security of your system.
The server-side validation must always be done and nothing will make your server automatically safe (safe from what? you have to decide what input is safe for your application, your database, your users, how it will be used etc.).
The only easy way to reuse your client-side validation code on the server side is to use Node.js or other server-side JavaScript like Rhino.
Unfortunately not, you need to validate server side to keep it safe.
Any thing you do client side can be undone by a malicious user. Generally, client side validation is used for quicker feedback to the user and to prevent your server getting too many hits. So it is still very beneficial, but you will need both.
i have a form with 20 fields .. i have 2 options ...one to validate on client side and another on click of submit button do a validation from server side using ajax and show result.....
which 1 to choose...which is faster server side or client side..
i am developing a application ..its not a website.
i would do both.
client side should be easy with jquery validation plugin if the form is nothing out of the ordinary.
server side if you use any framework at work, it could be quick. if not it's just a lot of typing.
Always do server-side, regardless of speed. Client side is optional and will be faster, but can be disabled by disabling Javascript, and you do not want to implicitly trust user input.
I am working on a J2EE web application
Here we are using JSP and Struts
I know one can use
Client side validation (Using JavaScript)
Server side validation (Using Validation framework)
My question is which way is more proper and one should use in application and why?
You have to use both.
Server side validation is required so that nobody can use malformed queries and gain access to your data. You must do server side validation because anybody can submit malformed queries to your page directly (rather than going through your client side scripts)
Client side validation is only to help innocent users submit correct data in case they were making a mistake which would have cost an entire trip to the server and a page reload to be detected and displayed otherwise.