Validation, output encoding and parameterized queries solve different problems. Validation checks that data is acceptable. Output encoding makes data safe to show in a page. Parameterized queries make data safe to use in SQL. Using one in place of another is how many injection bugs survive code review.
Validation: is this data acceptable?
The OWASP Input Validation Cheat Sheet separates two kinds. Syntactic validation checks type and format, such as a number, a date or a length. Semantic validation checks that the value makes sense for the operation, such as an end date that falls after the start date.
It recommends allowlists, which define what is accepted and reject the rest, over denylists, which try to recognize malicious input. Denylists miss cases, and the cheat sheet's example is blocking apostrophes, which rejects legitimate names without making a query safe.
Validation must run on the server. Browser checks can be bypassed and only provide quick feedback.
Output encoding: can this be shown safely?
Cross-site scripting happens when data ends up in a page in a form the browser treats as code. The cheat sheet states that validation does not prevent XSS, and context-aware output encoding does. Context matters because the right encoding for HTML text differs from the right one for an attribute, a script or a URL.
Use your template engine's automatic encoding, and treat any switch that disables it as a risk.
Parameterized queries: can this be used in SQL?
SQL injection happens when data is concatenated into a query so it changes the query's meaning. The cheat sheet says validation does not make SQL safe, parameterized queries do. With parameters, the database receives the query and the values separately, so a value can never become part of the command.
Why "cleaning" input is a trap
Stripping suspicious characters can change a value's meaning and still provides neither parameterization nor encoding. The page puts the split plainly: validation decides whether data is acceptable for the application to use, while parameterization and output encoding control how that data is used safely afterward.
A decision table
- Is the value the right type, size and range?: Server-side validation with an allowlist
- Does the value make sense for this action?: Semantic validation
- Will the value appear in HTML, a script or a URL?: Context-aware output encoding
- Will the value be part of a database query?: Parameterized queries
- Will the value be used in a shell command or path?: Avoid the shell; use APIs with arguments; validate against an allowlist
The last row is general practice rather than a quote from the cheat sheet. It follows the same principle of keeping data separate from commands, so check your language's own guidance.
A short workflow
- List where untrusted data enters: forms, URLs, headers, files, APIs.
- Validate on the server with allowlists as early as possible.
- At every place data leaves for another system, use the control for that system: encoding for pages, parameters for queries.
- Test with hostile values, including quotes, angle brackets and very long strings.
- Add a code review rule: no string concatenation into queries or HTML.
Where Safeguard fits
Static and dependency checks can flag known unsafe patterns and vulnerable libraries, but they cannot know what your data should look like. Run a free scan for the library side and keep the validation rules in your own tests.
Quick check
If I validate strictly, can I skip encoding?
No. Some valid values, such as names with apostrophes, are still unsafe in the wrong context. Encode on output.
Is client-side validation useless?
No, it helps users. It is not a security control.
Sources
Last reviewed: 19 October 2026.
