Home / Knowledge hub / Input validation
Knowledge hub
Input validation
Checking that what arrives is the shape and range you expected.
What it means
Input validation checks incoming data at the point it arrives. The right type, a sensible length, a plausible range, a known format, and one of the values that field may hold.
The strong version is an allowlist. OWASP puts it bluntly: define exactly what is authorised, and by definition everything else is not. A denylist tries to name every bad input in advance and loses to the one nobody predicted.
Why it matters
Validation is cheap, it runs early, and it removes a wide band of malformed input before that input reaches code never written to handle it. Everything downstream gets easier to reason about, because each later step can assume the data is at least well formed.
What it cannot do is decide whether an action is allowed. Validation rejects a quantity of -5. It has nothing to say about a quantity of 1 on somebody else's order, because that input is perfectly valid and the problem is who sent it. Validation and authorisation answer different questions.
How it shows up
The common gap is trusting the browser. OWASP is explicit that server-side validation must happen before any processing, since anyone can disable JavaScript or send requests straight through a proxy. Client-side checks are a courtesy to the user and nothing more.
After that, look at the quiet places. Optional fields that skip the check. Values from a partner API. Data read back out of your own database after years of storage. File uploads, where the name, the size, the declared type and the actual contents each need separate attention.
Questions people ask
Input validation, answered
Is client-side validation enough?
No. Anyone can bypass it with browser tools or by sending the request directly to your API, and adding fields your form never showed is trivial.
Keep it for the user experience, because instant feedback is kind. Enforce the same rules again on the server, where nobody can skip them.
What is the difference between validation and sanitisation?
Validation asks whether the input is acceptable and rejects it if not. Sanitisation changes the input, stripping or encoding parts of it, and then carries on.
Reject where you can. Silently modifying what somebody sent tends to produce surprising data later and hides the fact that something odd arrived.
Allowlist or denylist?
Allowlist, wherever the field has a knowable shape. You state what is permitted and everything else fails, so you never have to predict the next clever payload.
Denylists have a place as an extra layer for logging odd traffic. They are a poor primary control.
Does validation stop SQL injection?
It reduces the surface and it is not the fix. A perfectly valid name like O'Brien breaks a badly built query, and a strict format check on one field says nothing about the other twelve.
Parameterised queries fix injection. Validation keeps nonsense out of your data.
Do I need to validate data from our own systems?
Yes. A partner feed, an internal service or a row stored years ago all arrive as data you did not create here. Any of them can be wrong.
Teams trust internal traffic far more than it deserves, which is exactly how one compromised service turns into several.
Sources
Where this comes from
Related
Terms that sit next to this one
Injection
Input that ends up running as a command instead of being read as text.
Untrusted input
Anything that arrived from outside your own code, and is therefore suspect.
Allowlist
A list of what you permit, with everything else refused by default.
Mass assignment
When the fields in a request get written straight onto a record.
Business logic flaw
Nothing is technically broken, but your own rules turn against you.
Valid input, wrong owner
Validation stops malformed data, never the wrong person. We test what your application accepted when it should have refused, and our business-logic module joins that work on 4 January 2027.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.