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?
Top comments (48)
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
swaggeroropenapifile (*.json/*.yaml) and use it in the client seems to be the closest way I know.Yeah true, Swagger would be helpful
I like the idea of validating on both sides honestly.
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.
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.❤️
just a reminder:
curlis a thingBecause 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 🪓
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
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.
Yes.
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. 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.
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 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.
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)
Well, actually Both.
Why not, only Server-side???
Why not, only Client-side???