Home / Knowledge hub / Input sanitisation
Knowledge hub
Input sanitisation
Cleaning or stripping risky characters from input, which is weaker than encoding.
What it means
Input sanitisation means cleaning data as it arrives, for example by stripping script tags, removing quotes or deleting odd characters, so that it is harmless later. It is a common first instinct when teams hear about injection. Both sound sensible, and neither is enough.
The trouble is that cleaning guesses what will be dangerous, and danger depends on where the data ends up. Text safe in a web page is not safe in a database query, a file path or a shell command. That is why stronger, destination-specific controls exist.
Why it matters
Sanitising leaves gaps attackers learn to exploit. A filter that removes a word once can be beaten by hiding the word inside itself. A list of bad characters misses one. Cleaning at the wrong point changes real data too, mangling names with apostrophes and breaking legitimate customers.
Teams that rely on it often believe the problem is solved, and so skip the stronger controls. The injection flaws found in a test then come from exactly the place everyone thought was covered. Real protection comes from the destination-specific controls underneath.
How it shows up
You meet it as filter functions, blocklists of bad words, regular expressions that delete characters, and generic middleware that cleans every request. The better pattern is to handle each destination properly: parameterised queries for databases, output encoding for pages, and safe APIs for commands and files.
Use input validation to reject what does not match the expected shape, such as a number, a date or a short list of values. Where HTML from users must be allowed, use a maintained sanitiser library with a strict allowlist, not your own pattern. Test with encoded and nested payloads.
Questions people ask
Input sanitisation, answered
What is the difference between sanitising and validating?
Validating checks input against what is expected and rejects it if it does not fit. Sanitising changes the input to make it acceptable.
Rejecting is usually safer than silently rewriting.
Is sanitising the same as encoding?
No. Encoding makes data safe for one specific place, such as HTML, by representing special characters so they are shown rather than run. Sanitising removes or alters the data.
Output encoding for the right context is the stronger defence.
Why do blocklists fail?
Because attackers only need one variant you did not list: a different case, an encoding, a nested form or a character you forgot.
An allowlist of what is permitted is much harder to get around.
When is sanitising the right tool?
When you must accept rich content, such as HTML from an editor, a maintained sanitiser library with a strict allowlist is appropriate.
Even then, pair it with output encoding and a content security policy.
How do we test for weak sanitisation?
Try nested, encoded and mixed-case variants of known payloads in each field, and see whether any survive and reach a page, query or file.
A payload that survives shows where the real control is missing.
Related
Terms that sit next to this one
Input validation
Checking that what arrives is the shape and range you expected.
Output encoding
Escaping data for its destination so it is shown as text, not run as code.
Parameterised queries
Sending the query and the data separately so input can never become code.
Injection
Input that ends up running as a command instead of being read as text.
Allowlist
A list of what you permit, with everything else refused by default.
Did the filter really stop it?
Filters create confidence that often is not earned. We try nested and encoded input against your fields and report only what got through, with the request and the response. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.