What is input validation? (and why AI code often skips it)

What it actually is

Input validation is the check your app runs on incoming data before doing anything with it. A signup form sends an email and a password. A checkout sends a quantity. A URL carries an id. Validation asks a plain question about each one: does this match what I expect? An email shaped like an email, a quantity that is a positive whole number. Anything that fails gets rejected with a clear error before it touches your database.

Think of a restaurant kitchen taking a delivery. Before anything goes in the walk-in, someone checks the boxes: is this what we ordered, in the right quantity, and not spoiled. Nobody cooks straight from an unopened crate. Your server is the kitchen, and every incoming request is a crate from outside.

The rule underneath all of it: never trust anything a user types or sends. Not because your users are villains, but because “user” here means anyone on the internet who can reach your API endpoint, including bots and scripts that never open your site at all.

Why your AI just did this

AI-generated code often skips server-side validation unless you ask for it. Your agent builds the version of the feature that makes the demo work: a form that submits and an endpoint that writes the row. It may add browser-side checks (required on inputs, a red border under a bad email) because those are visible in the demo. The invisible half, an endpoint that rejects garbage, tends to appear only when you request it or when the framework forces it.

Those browser-side checks are UX only: they help honest users fix typos before submitting. Anyone else can open the dev tools Network tab, right-click your form’s request, choose Copy > Copy as cURL, edit the body to whatever they want, and send it straight to your server. If the endpoint accepts it, the form’s checks never mattered. OWASP’s guidance is blunt about this: validation must happen on the server before data is processed, because client-side JavaScript checks can be circumvented.

When your agent does add validation, you’ll usually see it as a schema library. In JavaScript projects that’s often zod (a schema per request body, checked at the top of the handler) or express-validator in Express apps; Python agents reach for Pydantic. The pattern is the same everywhere: define what a valid request looks like, reject everything else with a 400.

When you’ll run into it

The gentle version is broken data. You open your database table and find a name that is 4,000 characters of pasted text, a price of -1, or an empty string where an email should be. Nothing hacked you. The endpoint accepted whatever arrived, and now your app crashes trying to render it.

The louder version is errors. A 500 when someone submits text into a field your database typed as a number, or Postgres complaining invalid input syntax for type integer: both are an endpoint doing no checking and letting the database be the first thing to object. Express apps have a third flavor, a PayloadTooLargeError when a request body exceeds the parser’s default 100kb cap. That one comes from the framework’s own limit, the only check standing between a giant paste and your database because the endpoint set none of its own.

The dangerous version is attacks. Unvalidated input is the front door for SQL injection (input treated as a database command) and XSS (input treated as code in someone else’s browser). Validation narrows that door; the locks are parameterized queries and output encoding, so you want both. Endpoints that accept anything also make cheap targets for scripted abuse, which is where a rate limit earns its keep. And if your app feeds user text to an LLM, the same never-trust-input rule reappears as prompt injection.

What to check

• Ask your agent to list every endpoint that writes to the database, then confirm each one validates the request body on the server (form checks don’t count)
• Test one endpoint yourself: in the Network tab, right-click your form’s request, choose Copy > Copy as cURL, change a value to nonsense, and run it. A healthy endpoint answers 400
• Prefer allowlist rules that define exactly what is valid, rather than filtering out known-bad characters, which attackers route around
• Set boundaries on everything: max lengths on strings, ranges on numbers, a fixed list for anything that is a choice, and a request body size limit
• Keep validation paired with parameterized queries and output encoding, since OWASP is explicit that validation alone is not the primary defense against SQL injection or XSS
• Return a 400 with a plain message when input fails, so bad data gets refused loudly instead of stored quietly

Say it like a dev

Instead of: “people can type weird stuff into my form and it breaks the app” Say: “Add server-side validation to every endpoint that writes: check each field’s type and range with a zod schema, and return a 400 when the body fails”

Instead of: “the form already checks the email, so we’re fine” Say: “The browser check is UX only. Enforce the same rules on the server, since anyone can bypass the form with curl”

Instead of: “make it so hackers can’t send bad data” Say: “Validate request bodies against an allowlist schema before any database write, and use parameterized queries for every user-supplied value”