input-validation

name	input-validation
description	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)
license	MIT
metadata	{"displayName":"Input Validation & Output Encoding","author":"Tyler-R-Kendrick"}
compatibility	claude, copilot, cursor
references	[{"title":"OWASP Input Validation Cheat Sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html"},{"title":"OWASP Cross-Site Scripting Prevention Cheat Sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html"},{"title":"OWASP SQL Injection Prevention Cheat Sheet","url":"https://cheatsheetseries.owasp.org/cheatsheets/SQL_Injection_Prevention_Cheat_Sheet.html"}]

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

1. Validate as early as possible — at the API boundary, form handler, or deserialization layer before data enters business logic.
2. Normalize before validating — decode, trim, and canonicalize input before applying validation rules. Attackers exploit double-encoding and Unicode normalization differences to bypass checks.
3. 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.
4. 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	[e-mail] — verify domain has MX records
URLs	Scheme allowlist (https only), reject internal/private IPs