Home / Knowledge hub / Untrusted input
Knowledge hub
Untrusted input
Anything that arrived from outside your own code, and is therefore suspect.
What it means
Untrusted input is anything that arrived from outside your own code. Form fields and URLs, plainly, but also headers, cookies, uploaded files, webhook payloads and a partner's API response.
Untrusted does not mean malicious. It means you did not write it, so you cannot assume anything about its shape, its size or its contents.
Why it matters
Treating all of it as suspect is the single habit that prevents most injection bugs. Nearly every class with a memorable name traces back to input somebody trusted, including SQL injection, cross-site scripting and path traversal.
The expensive mistake is deciding some sources are safe. OWASP says outright that feeds from suppliers, partners and other internal systems need the same validation as a public web form. That is usually exactly where the checks turn out to be missing.
It is also the cheapest habit to teach. A team that treats every boundary the same way avoids whole families of flaw without learning the names of any of them.
How it shows up
Look at the boundaries. Validate on arrival against what you expect, using a list of allowed values rather than a list of banned ones. Then escape on the way out, according to where the value is going: a page, a query, a shell, a filename.
Your own database counts too. Data a user stored last month is still untrusted when you read it back, which is how stored cross-site scripting survives. File uploads deserve real care. The filename, the declared type and the actual contents are three separate pieces of untrusted data, and most applications check only one of them.
Questions people ask
Untrusted input, answered
What is the difference between validation and sanitisation?
Validation asks whether the value matches what you expect and rejects it if not. Sanitisation changes the value to make it safe for a particular destination.
Validate on the way in, escape on the way out. Rewriting input on arrival tends to hide bugs rather than fix them, because you no longer know what the user actually sent.
Is client-side validation enough?
No, and it never was. Anybody can send the request straight to your API and skip the page entirely.
Keep the browser checks, because they give people quick feedback. Just treat them as a convenience rather than a control, and repeat every rule on the server.
Allowlist or blocklist?
Allowlist, whenever you can describe what good input looks like. A blocklist only stops the attacks somebody already thought of, and encodings give attackers endless ways around it.
Blocklists earn their place in free text fields, where you genuinely cannot enumerate the valid answers.
Is data from another internal service untrusted?
Yes. That service takes input from somewhere, and it may be compromised, misconfigured or simply buggy.
This is the most common blind spot in practice. The public-facing boundary gets careful attention, and the internal one gets none at all.
Does my framework not handle this already?
Partly. Modern frameworks parameterise queries and escape template output, which removes a large share of the classic mistakes.
The gaps show up where you step outside those defaults. Raw SQL for a reporting query. Raw HTML for a rich text field. A shell command you assemble from a filename.
Sources
Where this comes from
Related
Terms that sit next to this one
Input validation
Checking that what arrives is the shape and range you expected.
Injection
Input that ends up running as a command instead of being read as text.
XSS
An attacker's script running in your pages, in your customers' sessions.
SQL injection
Input a database ends up running as part of a query.
Allowlist
A list of what you permit, with everything else refused by default.
Which of your boundaries went unchecked?
Injection, cross-site scripting and SSRF all trace back to input somebody trusted, and all three sit among the ten classes Cyberlop tests. Ask for a run on one application.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.