Input Validation & Output Encoding
Overview
Input validation and output encoding form a defense-in-depth strategy against injection attacks. Neither is sufficient on its own:
- Input validation ensures that data conforms to expected formats before processing. It reduces the attack surface but cannot account for every output context.
- Output encoding ensures that data is rendered safely in its target context (HTML, SQL, JavaScript, etc.). It neutralizes malicious content but should not be the only line of defense.
Always apply both: validate all input as early as possible, and encode all output as late as possible — immediately before it is rendered or interpreted in its target context.
Input Validation Strategy
Allowlist vs. Denylist
- Always prefer allowlist (positive) validation. Define what is permitted and reject everything else. Allowlists are explicit, predictable, and far harder to bypass.
- Denylist (negative) validation is fragile. Blocking known-bad patterns always misses novel attack vectors, encoding tricks, and edge cases.
Principles
- Validate as early as possible — at the API boundary, form handler, or deserialization layer before data enters business logic.
- Normalize before validating — decode, trim, and canonicalize input before applying validation rules. Attackers exploit double-encoding and Unicode normalization differences to bypass checks.
- Use typed validation — parse inputs into their expected types (integers, dates, enums) rather than treating everything as strings. Type coercion eliminates entire classes of injection.
- Validate on the server side — client-side validation improves UX but provides zero security. All validation must be enforced server-side.
Validation by Data Type
| Data Type |
Validation Rule |
Example |
| Strings |
Max length, allowed character set, regex pattern |
Username: ^[a-zA-Z0-9_]{3,30}$ |
| Numbers |
Type check, min/max range, integer vs. float |
Age: integer, 0-150 |
| Emails |
RFC 5322 format validation + DNS MX record check |
user@example.com — verify domain has MX records |
| URLs |
Scheme allowlist (https only), reject internal/private IPs |
Allow https:// only; block file://, javascript:, RFC 1918 ranges |
| File uploads |
MIME type check (magic bytes, not extension), max size, rename to random, virus scan |
Accept image/png up to 5MB; rename to UUID; scan with ClamAV |
| Dates |
Strict format parsing (ISO 8601), valid range check |
2024-01-15 — reject 0000-00-00, far-future dates |
Output Encoding
Output encoding must be context-specific. The correct encoding depends entirely on where the data is being rendered.
| Context |
Encoding Method |
Example |
| HTML body |
HTML entity encode |
<script> becomes <script> |
| HTML attributes |
HTML attribute encode |
"> becomes "> |
| JavaScript |
JavaScript encode / JSON.stringify() |
Embed user data only via JSON.stringify() into a variable assignment |
| URL parameters |
URL encode (percent-encoding) |
param=hello world becomes param=hello%20world |
| CSS |
CSS hex encode |
</style> becomes \003c\002fstyle\003e |
| SQL |
Parameterized queries ONLY |
Never encode manually for SQL — always use prepared statements |
Critical: HTML entity encoding does NOT protect against XSS in JavaScript or URL contexts. Each context requires its own encoding function.
Injection Prevention
| Attack |
Root Cause |
Prevention |
| SQL injection |
String concatenation in SQL queries |
Parameterized queries / prepared statements |
| XSS (Cross-Site Scripting) |
Unencoded user data in HTML output |
Context-specific output encoding; Content Security Policy (CSP) |
| Command injection |
String concatenation in shell commands |
Avoid shell execution; use language APIs with argument arrays |
| Path traversal |
Unvalidated file paths from user input |
Canonicalize paths; validate against an allowed base directory |
| LDAP injection |
Unescaped user input in LDAP queries |
LDAP-specific escaping functions; parameterized LDAP queries |
| XML injection |
Inline construction of XML from user data |
Use XML serialization libraries; disable external entities (XXE) |
Framework-Specific Helpers
Modern frameworks provide built-in protections. Understand what your framework does automatically and where gaps remain.
| Framework |
Built-in Protection |
| React |
JSX auto-escapes embedded expressions by default; beware dangerouslySetInnerHTML |
| Angular |
Template expressions are auto-sanitized; beware bypassSecurityTrust* methods |
| ASP.NET |
Razor views auto-encode output by default; beware Html.Raw() |
| Django |
Template engine auto-escapes variables by default; beware ` |
| Spring |
Thymeleaf auto-encodes with th:text; beware th:utext (unescaped) |
Warning: Every framework that auto-encodes also provides an escape hatch for raw output. Audit all uses of these escape hatches during code review.
Parameterized Queries
Parameterized queries (prepared statements) are the only reliable defense against SQL injection. Never construct SQL by concatenating user input.
SQL — Prepared Statement
-- Correct: parameterized query
SELECT * FROM users WHERE email = @Email AND status = @Status;
-- WRONG: string concatenation
SELECT * FROM users WHERE email = '" + email + "' AND status = '" + status + "';
ORM — Entity Framework (C#)
// Correct: LINQ query — parameterized automatically
var user = context.Users
.Where(u => u.Email == email && u.Status == status)
.FirstOrDefault();
ORM — SQLAlchemy (Python)
# Correct: ORM query — parameterized automatically
user = session.query(User).filter(
User.email == email,
User.status == status
).first()
Note on Stored Procedures
Stored procedures are not inherently safe from SQL injection. If a stored procedure uses dynamic SQL internally (e.g., EXEC or sp_executesql with concatenation), it is still vulnerable. Always use parameterized inputs within stored procedures as well.
Best Practices
- Validate all input on the server side — never rely on client-side validation for security.
- Use allowlist validation — define what is permitted and reject everything else; denylist approaches are inherently incomplete.
- Normalize input before validation — canonicalize Unicode, decode URL encoding, and trim whitespace before applying validation rules.
- Encode output for its specific context — HTML, JavaScript, URL, CSS, and SQL each require different encoding; there is no universal encoder.
- Use parameterized queries for all database access — never concatenate user input into SQL, regardless of prior validation.
- Avoid shell execution with user input — use language-native APIs with argument arrays instead of constructing shell command strings.
- Deploy Content Security Policy (CSP) headers — CSP provides an additional layer of defense against XSS even when encoding is missed.
- Audit framework escape hatches — review all uses of
dangerouslySetInnerHTML, Html.Raw(), |safe, th:utext, and similar raw-output functions during code review.
1---2name: input-validation-43description: Use when implementing input validation and output encoding to prevent injection attacks. Covers validation strategies, context-specific output encoding, parameterized queries, and defense-in-depth approaches across all languages and frameworks. USE FOR: input validation, output encoding, XSS prevention, SQL injection prevention, command injection prevention, parameterized queries, sanitization, allowlisting, content security policy DO NOT USE FOR: authentication validation (use authentication), API rate limiting (use api-security), cryptographic validation (use cryptography)4license: MIT5---6
7# Input Validation & Output Encoding
8
9## Overview
10
11Input validation and output encoding form a **defense-in-depth** strategy against injection attacks. Neither is sufficient on its own:
12
13- **Input validation** ensures that data conforms to expected formats before processing. It reduces the attack surface but cannot account for every output context.
14- **Output encoding** ensures that data is rendered safely in its target context (HTML, SQL, JavaScript, etc.). It neutralizes malicious content but should not be the only line of defense.
15
16Always apply both: validate all input as early as possible, and encode all output as late as possible — immediately before it is rendered or interpreted in its target context.
17
18## Input Validation Strategy
19
20### Allowlist vs. Denylist
21
22- **Always prefer allowlist (positive) validation.** Define what is permitted and reject everything else. Allowlists are explicit, predictable, and far harder to bypass.
23- **Denylist (negative) validation is fragile.** Blocking known-bad patterns always misses novel attack vectors, encoding tricks, and edge cases.
24
25### Principles
26
271. **Validate as early as possible** — at the API boundary, form handler, or deserialization layer before data enters business logic.
282. **Normalize before validating** — decode, trim, and canonicalize input before applying validation rules. Attackers exploit double-encoding and Unicode normalization differences to bypass checks.
293. **Use typed validation** — parse inputs into their expected types (integers, dates, enums) rather than treating everything as strings. Type coercion eliminates entire classes of injection.
304. **Validate on the server side** — client-side validation improves UX but provides zero security. All validation must be enforced server-side.
31
32## Validation by Data Type
33
34| Data Type | Validation Rule | Example |
35|---------------|-----------------------------------------------------------|----------------------------------------------------------|
36| Strings | Max length, allowed character set, regex pattern | Username: `^[a-zA-Z0-9_]{3,30}$` |
37| Numbers | Type check, min/max range, integer vs. float | Age: integer, 0-150 |
38| Emails | RFC 5322 format validation + DNS MX record check | `user@example.com` — verify domain has MX records |
39| URLs | Scheme allowlist (https only), reject internal/private IPs | Allow `https://` only; block `file://`, `javascript:`, RFC 1918 ranges |
40| File uploads | MIME type check (magic bytes, not extension), max size, rename to random, virus scan | Accept `image/png` up to 5MB; rename to UUID; scan with ClamAV |
41| Dates | Strict format parsing (ISO 8601), valid range check | `2024-01-15` — reject `0000-00-00`, far-future dates |
42
43## Output Encoding
44
45Output encoding must be **context-specific**. The correct encoding depends entirely on where the data is being rendered.
46
47| Context | Encoding Method | Example |
48|--------------------|----------------------------------|------------------------------------------------------------|
49| HTML body | HTML entity encode | `<script>` becomes `<script>` |
50| HTML attributes | HTML attribute encode | `" onclick="alert(1)` becomes `" onclick="alert(1)` |
51| JavaScript | JavaScript encode / `JSON.stringify()` | Embed user data only via `JSON.stringify()` into a variable assignment |
52| URL parameters | URL encode (percent-encoding) | `param=hello world` becomes `param=hello%20world` |
53| CSS | CSS hex encode | `</style>` becomes `\003c\002fstyle\003e` |
54| SQL | **Parameterized queries ONLY** | Never encode manually for SQL — always use prepared statements |
55
56> **Critical:** HTML entity encoding does NOT protect against XSS in JavaScript or URL contexts. Each context requires its own encoding function.
57
58## Injection Prevention
59
60| Attack | Root Cause | Prevention |
61|---------------------|------------------------------------|------------------------------------------------------------------|
62| SQL injection | String concatenation in SQL queries | Parameterized queries / prepared statements |
63| XSS (Cross-Site Scripting) | Unencoded user data in HTML output | Context-specific output encoding; Content Security Policy (CSP) |
64| Command injection | String concatenation in shell commands | Avoid shell execution; use language APIs with argument arrays |
65| Path traversal | Unvalidated file paths from user input | Canonicalize paths; validate against an allowed base directory |
66| LDAP injection | Unescaped user input in LDAP queries | LDAP-specific escaping functions; parameterized LDAP queries |
67| XML injection | Inline construction of XML from user data | Use XML serialization libraries; disable external entities (XXE) |
68
69## Framework-Specific Helpers
70
71Modern frameworks provide built-in protections. Understand what your framework does automatically and where gaps remain.
72
73| Framework | Built-in Protection |
74|-------------|----------------------------------------------------------------------------|
75| React | JSX auto-escapes embedded expressions by default; beware `dangerouslySetInnerHTML` |
76| Angular | Template expressions are auto-sanitized; beware `bypassSecurityTrust*` methods |
77| ASP.NET | Razor views auto-encode output by default; beware `Html.Raw()` |
78| Django | Template engine auto-escapes variables by default; beware `|safe` filter and `mark_safe()` |
79| Spring | Thymeleaf auto-encodes with `th:text`; beware `th:utext` (unescaped) |
80
81> **Warning:** Every framework that auto-encodes also provides an escape hatch for raw output. Audit all uses of these escape hatches during code review.
82
83## Parameterized Queries
84
85Parameterized queries (prepared statements) are the **only reliable defense** against SQL injection. Never construct SQL by concatenating user input.
86
87### SQL — Prepared Statement
88
89```sql
90-- Correct: parameterized query
91SELECT * FROM users WHERE email = @Email AND status = @Status;
92
93-- WRONG: string concatenation
94SELECT * FROM users WHERE email = '" + email + "' AND status = '" + status + "';
95```
96
97### ORM — Entity Framework (C#)
98
99```csharp
100// Correct: LINQ query — parameterized automatically
101var user = context.Users
102 .Where(u => u.Email == email && u.Status == status)
103 .FirstOrDefault();
104```
105
106### ORM — SQLAlchemy (Python)
107
108```python
109# Correct: ORM query — parameterized automatically
110user = session.query(User).filter(
111 User.email == email,
112 User.status == status
113).first()
114```
115
116### Note on Stored Procedures
117
118Stored procedures are **not inherently safe** from SQL injection. If a stored procedure uses dynamic SQL internally (e.g., `EXEC` or `sp_executesql` with concatenation), it is still vulnerable. Always use parameterized inputs within stored procedures as well.
119
120## Best Practices
121
122- **Validate all input on the server side** — never rely on client-side validation for security.
123- **Use allowlist validation** — define what is permitted and reject everything else; denylist approaches are inherently incomplete.
124- **Normalize input before validation** — canonicalize Unicode, decode URL encoding, and trim whitespace before applying validation rules.
125- **Encode output for its specific context** — HTML, JavaScript, URL, CSS, and SQL each require different encoding; there is no universal encoder.
126- **Use parameterized queries for all database access** — never concatenate user input into SQL, regardless of prior validation.
127- **Avoid shell execution with user input** — use language-native APIs with argument arrays instead of constructing shell command strings.
128- **Deploy Content Security Policy (CSP) headers** — CSP provides an additional layer of defense against XSS even when encoding is missed.
129- **Audit framework escape hatches** — review all uses of `dangerouslySetInnerHTML`, `Html.Raw()`, `|safe`, `th:utext`, and similar raw-output functions during code review.
majiayu000