loading...
Cover image for Input Validation: Client-side or Server-side?

Input Validation: Client-side or Server-side?

madza profile image Madza ใƒป1 min read

There is a rule of thumb to never trust the user input. That is where the input validation does come in.

Where do you normally do this? On the client-side to get quicker feedback to the user, on the server-side to protect against the malicious users, or do you use combination of both?

Discussion

markdown guide
 

From the server-side perspective, an extension to the "never trust the user input" rule of thumb is to never trust what the client-side sends you. With some knowledge of browser inspect tools (or tools like curl) people can easily tweak what the browser sends you, go around client-side validations and even add unexpected fields to the request.

So, security-wise server validations are very important. I would also add them on the client-side, but mostly to improve user experience - although they may also be useful if you have a lot of logic on the front-end and need to do things with the data the user gives you before sending it to the server ๐Ÿ‘

TLDR: use both! โœŒ๏ธ

 

Absolutely, the challenge then becomes how to avoid coding (and maintaining) your validations twice, especially if you're not using the same programming language on the server as on the client. There are solutions for this, but TBH for this reason I often do server side validation only. Doing only client side validation isn't safe, obviously.

 

Generating swagger or openapi file (*.json / *.yaml) and use it in the client seems to be the closest way I know.

Yeah true, Swagger would be helpful

 
 

I use both๐Ÿ™„,
Sigin Signup and Payment related stuff are with Server Side and
Comment/ contact with cleint side validation๐Ÿ˜....

I feel more safe....

 

This makes your comment/contact section easily hackable... You need server side validation always, client side is optional and for usability, performance and economic reasons

Yeah..
Never built such large user apps. so I have less exp with these things for sure will get into Server-side rather than client

Thanks

 

Server-side at two levels

Client side? Although I don't often allow text inputs, I actually apply validation as well as defensive programming quite often (I don't trust TypeScript). Also, if I allow user to input markdown, there will be DOMPurify.

And as Manolo said, text inputs need UI feedback, if it won't work anyway.

 

just a reminder: curl is a thing

 

Because hackers use UIs ๐Ÿ˜‰ (they do though)

 

I usually use both, front-end for feedback mostly, and to avoid unnecesary requests to the server.
And I go with the actual heavy validation on the server.

Give him feedback kindly ๐ŸŽˆ, but validate its input harshly ๐Ÿช“

 

Both/

/**
   * useful helper to detect if we have a sql injection attack. Should
   * implement this anywhere we are sending data or receiving data.
   *
   * sql regex reference: http://www.symantec.com/connect/articles/detection-sql-injection-and-cross-site-scripting-attacks
   * @param value
   * @returns {boolean}
   */
  static hasSQL(value) {
    if (value === null || value === undefined) {
      return false;
    }

    let sql_meta = new RegExp(
      "(%27)|(')|(--)|(%23)|(#)",
      "i"
    );
    if (sql_meta.test(value)) {
      return true;
    }

    /* eslint no-control-regex: "off" */
    let sql_meta2 = new RegExp(
      "((%3D)|(=))[^\n]*((%27)|(')|(--)|(%3B)|(;))",
      "i"
    );
    if (sql_meta2.test(value)) {
      return true;
    }

    let sql_typical = new RegExp(
      "w*((%27)|('))((%6F)|o|(%4F))((%72)|r|(%52))",
      "i"
    );
    if (sql_typical.test(value)) {
      return true;
    }

    let sql_union = new RegExp("((%27)|('))union", "i");
    return sql_union.test(value);
  }
 

Clientside for helpful error messages for the user and then serverside to just check it is right or wrong. I tend to give pretty generically named/labelled errors back from the server in case somebody is trying to find a vulnerability. Yes, there is often duplication but a necessary evil to make sure your application is both secure and user friendly.โค๏ธ

 

From My point of view...

I use Server Side Validation for Sensitive Forms like Sigin/Signup or Payment form

And Client side for
Comment's, leave a review or etc etc...

Why Server Side

Server side can't be broken easily, a experienced guy can deal with client side or broke Curl (Reminder)... whatever I am not much known of it...

I feel more safe using Server Side๐ŸŽ‰๐ŸŽ‰

Cheers to Server Side Validation ๐ŸŽ‰

 

then I can easily add malicious code into your comments section easily by disabling javascript or sending a request from a script to your non-securized server side comments handler :v

 
 

But really, ideally I'd do both always, but client-side validation and proper input escaping goes a long way IF the backend runs on a closed API.

I never skip client-side validation because I hate when I don't know what type of data the server expects, it is just bad UX.

 

Both, client-side for UX, so the user gets direct feedback. And server-side to really validate/verify the data and prevent errors.

At least the API should have validation or users will exploit it sooner or later.

 
 

Both. Always.

Client-side: Do it early and do it with usability. (e.g) Phone number field has the right format depending on the country and area code.

Server-side. Do it ALWAYS. Never trust the client. Client could be a browser, mobile app, or API client. For the phone number provided, validate for format but more importantly check against blocked number database, spam numbers or send an OTP - whatever the biz logic is.

 

I agree to both. You want client side so that you don't have to make a post to your server if you don't have to, as well server, in case there is either an injection hack or the client side code doesn't work correctly (how much code doesn't work, or works different in internet explorer)

 

Both, always! It is important to have client side to ensure better UX and avoid unnecessary requests to the server.

On the other side, do it on the server side always as validation is very necessary to mantain integrity of your data. Also, you can plug your server to different clients and don't have to remember to do all of those validations again ;)

 

IMO, we should have the validation on both.

Server Side Validations: Whether you are having validations in client or not. You must have all the validations in server. Since the server only has high responsible for storing the valid data and to protect malicious data sent from the user. So you must have all the field validations in server.

Client Side Validations: This is for users usability experience. Through client validations you can avoid unnecessary network calls by which user can instantly aware of the possible field values and correct it. So, client side Validations are โ€œa nice to haveโ€ to improve the user experience.

 

Both. Validation for UX is a must and people can bypass the client if they know-how.

I have had some disagreements with BEers who think that if it's in the Frontend there's no need. And I'm just like

what ... blinks becomes worried about any other code they've touched

 

The only answer is both, for the simple reason your server can't trust anything it's receiving and the client needs to make sure it adheres to the constraints set by the contract (API, Websocket, GraphQL etc.)

 

It is very simple. As you already have decoupled client and server you have 2 edges in your system. The only correct answer would be both.

  • you want your client to provide valid data to the backend + direct feedback to users.
  • you want your backend to only accept valid data as you probably want to prevent any sort of intrusion (Remote Code Execution, Injection etc.).

You can test both modules separately and more important if someone else connects to the backend (either legit or not) your data processing is always clear.

 

Both of course.

You need some filter on client side to avoid sending requests that will lead to failure, then you need validation on server side that match the app logic.

This is because validate things only on client side will make your APP easily hack-able by simply disabling javascript or other techniques.
Apart from that you want to avoid requests that you already know they will return some error because this makes your cloud costs cheaper and on high server load situation you'll get more resource margin.

Given that, I would say that client side validations are meant for giving fast feedback to the user (usability reasons) and for avoiding unnecessary extra requests to the server (economic and performance reasons).

And server side validations are for security reasons.

 

Always have server-side validation in place, and then if you want to make your user interfaces more responsive, then have it on the client-side as well, but you should never omit it from server-side. The client-side validation is simply there to improve the user experience, while the server-side validation is there to ensure that the data you receive is in the format you expect and that nothing nefarious can occur.

 

What do you think of a something like this: github.com/voku/HtmlFormValidator

How does this work?

  1. First you need to generate a html form, that's completely your part. You can write it manually or you can generate with a framework or a library, it doesn't matter.

  2. Then we use DOM Parsing via voku/simple_html_dom, to detect the current validator and filter rules directly from the html.

  3. And finally, we use Respect/Validation to validate the form.

 

Client side validation is only helpful to save roundtrip to server to perform simple validations. Basically save costly cpu resource and bandwidth of server, and save time of user.

Server side validation is must, hackers will try all sort of combinations to bring down server, steal information.

 

Well, actually Both.

Why not, only Server-side???

  • It will be slower and not realtime
  • Every time requesting the server will be an overhead for the server.

Why not, only Client-side???

  • Browsers can be set to disable Validations.
  • Scripts can be manipulated in the browser.
 

Server side for security. Client side for UX

 
 

Use both. The client side validations for a normal person so that it provides faster response time. The server side validations for tricksters and for complex business validations that are too heavy for client side.

 

Client-side for convenience and to delight your users (or at least to not infuriate them), but only ever trust server-side.

 

Should have both server and client side validation.

 

Both. Is the best answer. Client side is there for user experience, backend for security. Find a way that validation can be isomorphic such as json schema and your golden.

 

I usually do both, just to in case you know haha

 

Client Side - real time error handling and no need to request the server
Server Side - last line of defense for error handling

Yes you can do both but the question would be, are you okay on maintaining both sides?

 

I agree with everyone else using both methods gives you a double layer of security.

 

Server side or combination of both.

 
 

You must have on the server, nice to have on the client (client validation is often for UX not data integrity)

 

I do it both sides: client side validation catches unwilling and innofensive mistakes. Server side validation is aimed at crackers.

 

At least server-side! Both is preferred for a better UX.