DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’»

DEV Community πŸ‘©β€πŸ’»πŸ‘¨β€πŸ’» is a community of 963,673 amazing developers

We're a place where coders share, stay up-to-date and grow their careers.

Create account Log in
Cover image for Input Validation: Client-side or Server-side?
Madza
Madza

Posted on

Input Validation: Client-side or Server-side?

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 (50)

Collapse
 
pedrogaspar profile image
Pedro Gaspar • Edited on

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! ✌️

Collapse
 
leob profile image
leob • Edited on

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.

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt • Edited on

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

Thread Thread
 
leob profile image
leob

Yeah true, Swagger would be helpful

Collapse
 
leeiaah_ profile image
이아 | Nessa Okeke

I like the idea of validating on both sides honestly.

Collapse
 
ben profile image
Ben Halpern

why not both

Collapse
 
hemant profile image
Hemant Joshi

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

I feel more safe....

Collapse
 
joelbonetr profile image
JoelBonetR

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

Thread Thread
 
hemant profile image
Hemant Joshi

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

Collapse
 
patarapolw profile image
Pacharapol Withayasakpunt • Edited on

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.

Collapse
 
nialljoemaher profile image
Niall Maher

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.❀️

Collapse
 
darkwiiplayer profile image
π’Š©Wii πŸ’–πŸ’›πŸ’šπŸ’™πŸ’œπŸ’πŸ’Ÿ

just a reminder: curl is a thing

Collapse
 
adam_cyclones profile image
Adam Crockett • Edited on

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

Collapse
 
nomade55 profile image
Lucas G. Terracino • Edited on

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 πŸͺ“

Collapse
 
hemant profile image
Hemant Joshi • Edited on

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 πŸŽ‰

Collapse
 
joelbonetr profile image
JoelBonetR

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

Collapse
 
vtrpldn profile image
Vitor Paladini

Yes.

Collapse
 
vtrpldn profile image
Vitor Paladini

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.

Collapse
 
omaratta212 profile image
Omar Atta

Both

Collapse
 
nombrekeff profile image
Keff

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.

Collapse
 
ramesh profile image
Ramesh Elaiyavalli

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.

Collapse
 
joelbonetr profile image
JoelBonetR

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.

Collapse
 
soheilbj profile image
soheil bijavar

for security reason must be have on server validation but for create more performance and don't create load on server you must implement client side validation at last both of them in enterprise applications are required

Collapse
 
neelam28 profile image
Neelam

I'm currently working on something which requires users to register themselves before using the app.

And this was the question that I wrote into Google "what to choose for validation javascript or php".

And your question seems exactly the same!

As my app is something very tiny that I'm only building to solidify my concepts.

Collapse
 
akashkava profile image
Akash Kava

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.

πŸ‘€ Just want to lurk?

You can still create an account and turn on features like 🌚 dark mode.