It's not a security feature, it's a UX feature.

I'd argue it's often an anti-feature.

These validation at input can be super annoying when you're copy-pasting your strings from other sources, and want to edit them in textbox in-place. Especially if you're on your phone.

I've be frustrated by this on numerous websites, a lot.

Another common failure case is only updating the validation state on key presses but not other content changes like auto fill.

True, but if there's a communication bug between UX and back-end teams, that can escalate into a false sense of security and then an exploit.

What the hell back-end team relies on their front-end teams to tell them to do input checking?

Nothing my front-end people could possibly do would trick me into trusting user input.

in 2025? you'd hope not

but also cross-system context switches, amateur RegExp, escape character (ab|mis)use, etc. can make "user-input" propagate farther than any one team's boundaries.

assertions/test coverage/fuzzing at every boundary so user-input taint analysis can't fail is a requirement for a system that passes user data around more than one time or tech stack.

> True, but if there's a communication bug between UX and back-end teams, that can escalate into a false sense of security and then an exploit.

How so? The backend ALWAYS validates. No communication necessary, whether or not the frontend also validates doesn't matter to the backend. Frontend validation is to improve user experience, nothing more.

>Frontend validation is to improve user experience, nothing more.

and to reduce server load.

  >The backend ALWAYS validates.

Exactly. Sometimes in a system so big compartmentalization is required yet meta-communication is inhibited, that comfort-ability can lead to false asserts / assumptions.

"We always validate - no need for _me_ to do it" type bystander effect / diffusion of responsibility.

That's one benefit of using ts on server. We share same zod validation on both end.

You were being downvoted here, but I think you make a great point.

The problem with having separate client-side and server-side validation logic is that you (generally) want the rules to be the same, but you end up needing to write them twice, usually in completely different technologies. I have seen many, many cases where the client-side validation and server-side validation got out of sync, and then just like you put it, obscure bugs or security exploits can arise from this.

In general, I think client-side validation should really only be used for the basics, often with respect to type (e.g. the email/URL examples given) and just basic "required" (non-empty) fields. Anything more complicated than that should be done solely server-side in my opinion - e.g. I wouldn't use setCustomValidity with a complex set of client-side rules. What I think is important, though, is to ensure that if the server validation fails that the error message that comes back is not just a single "Bad input!" message, but errors can be keyed by field to ensure you can display field-specific error messages and error highlighting.

Another option I considered back in the day when my backend was on NodeJS is to have the server return the text for a JavaScript validation function before the form itself is actually rendered. This, this function can be run client-side for immediate feedback when the user submits the form, but it's also the exact same logic that is run on the server when the form values are received.

This was one of the biggest "oh shit" moments I had when learning Remix: I could reuse the same validators across front and backend and they could even be right there in the same file.

It's a UX feature, absolutely, but you can't trigger the browsers validators from the backend, so you'd need to implement your own styling anyway, probably even add a bit more information than the browser can natively handle.

Couldn't have said it better!