What is server-side validation?
Server-side validation checks every incoming request against expected rules before acting on it — required fields, types, ranges, formats. It is the non-negotiable guard at the boundary, because anything from the network is untrusted, no matter what the client UI enforces.
Why it matters
The client cannot be trusted: requests can be forged, replayed, or sent directly without your UI. Server validation is the real line of defense for data integrity and security. Skipping it because the form already validates is one of the most common and serious full-stack mistakes.
What to learn
- Why all client input is untrusted
- Validating with a schema library (Zod)
- Sharing the schema with the client
- Returning clear, structured validation errors
- Validating types, ranges, and formats
- Sanitizing and normalizing input
- Failing with the right status code (
400)
Common pitfall
Validating only on the client and assuming the server can trust what arrives. An attacker bypasses the UI entirely and posts whatever they want straight to the endpoint. Always validate on the server, even when the client also does — and ideally share one schema so the rules cannot drift between the two.
Resources
Primary (free):
- Zod — Documentation · docs
- OWASP — Input validation cheat sheet · docs
- MDN — Status 400 · docs
Practice
Add Zod validation to an endpoint: define a schema for the request body, reject
invalid input with a 400 and a structured error, and accept valid input. Reuse
the same schema the client form uses. Confirm a direct request with bad data is
rejected even though it never touched the form. Done when the server guards the
boundary.
Outcomes
- Validate all incoming requests on the server.
- Use a schema library and share it with the client.
- Return structured errors with the right status code.
- Treat client validation as UX, server validation as security.