What they're testing
Whether you treat the client as hostile territory — the foundation of all web security.
The short answer~30 seconds
On the client for the EXPERIENCE: fail fast, don't make someone wait a round trip to learn they typed their email wrong. On the server for SECURITY: everything client-side is editable — DevTools, curl, or a hand-written client — so a check there isn't a defence, it's a suggestion. The rule: the client validates to help honest users, the server validates to stop dishonest ones.
The long answer
What makes this durable is sharing ONE schema definition across both sides — Zod being the standard example: one schema runs in the form and in the server action, so the two can't drift. When the definition is duplicated, eventually someone loosens one side and forgets the other, and the hole sits exactly in that gap.
The commonly-missed part is that server-side validation must be an ALLOW-list rather than a deny-list, and must cover fields the UI never shows. A profile-update endpoint that takes the whole object and writes it will happily accept a role: "admin" field no form ever sent — mass assignment, and the reason you enumerate permitted fields rather than excluding forbidden ones.
What they'll ask next
?Sanitising versus validating?
Validating rejects invalid data; sanitising transforms it into something safe. The pragmatic rule: validate on INPUT, sanitise on OUTPUT and per context — the same string needs different escaping going into HTML, into an attribute, or into a shell command.
These lose points
- Client-only validation because "our API is internal". Internal today is public after the next refactor.