# Input Validation Patterns

> Design and implement input validation patterns (whitelisting, boundary checks, type validation) to prevent injection and buffer overflow attacks.

- Skill: `sethdford/input-validation-patterns` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sethdford/input-validation-patterns`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sethdford/input-validation-patterns/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: sethdford (https://skillmd.com/u/sethdford)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sethdford/input-validation-patterns

---


# Input Validation Patterns

Design robust input validation using whitelisting, boundary checks, and type validation.

## Context

You are a senior security architect designing input validation for $ARGUMENTS. Input validation is the first line of defense against injection attacks, buffer overflows, and malformed-data exploitation.

## Domain Context

- **Whitelisting vs. Blacklisting**: Whitelist allowed characters/patterns (safe-list approach); blacklisting is fragile and incomplete
- **Validation Points**: Validate at every trust boundary; don't assume data from database or internal APIs is safe
- **Canonicalization**: Normalize input (remove encoding, aliases) before validation (e.g., `../../etc/passwd` → `/etc/passwd`)
- **Type Safety**: Enforce data types (integer, email, UUID); avoid string representations that get misinterpreted

## Instructions

1. **Define Validation Rules** for each input:
   - **Type**: Integer, string, email, UUID, date, IP address, etc.
   - **Length**: Min and max length (prevents buffer overflow, DoS)
   - **Format**: Regex or pattern (email: `^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
   - **Range**: Min/max value for numbers (e.g., age 0-150, quantity 1-1000)
   - **Allowed Characters**: Whitelist (e.g., for filename: alphanumeric, dash, underscore only)
   - **Business Rules**: Must be unique, must exist in reference table, must be in future, etc.

2. **Implement Whitelisting** (not blacklisting):

   ```
   Bad (blacklisting): Remove dangerous characters (always incomplete)
   input = input.replace("'", "").replace(";", "")

   Good (whitelisting): Accept only known-safe characters
   if (!preg_match('/^[a-zA-Z0-9_-]*$/', input)) { reject }
   ```

3. **Canonicalize Before Validation**:
   - URL-decode: `%2e%2e%2f` → `../`
   - HTML-decode: `"` → `"`
   - Remove null bytes (legacy, but still relevant)
   - Normalize paths: resolve `..` and `.` before checking against allow-list

4. **Validate at Boundaries**:
   - User input from web forms → validate
   - API parameters → validate
   - Database queries (even if from trusted system) → prepare statements
   - File uploads → validate MIME type, size, content
   - Configuration files → validate before use

5. **Handle Validation Failures Securely**:
   - Reject invalid input; don't try to "fix" it
   - Log validation failures (don't expose to user)
   - Return generic error to user ("Invalid input")
   - Alert on repeated failures (possible attack)

## Anti-Patterns

- Blacklisting dangerous characters; **always use whitelisting**
- Trusting data from "internal" sources; **validate at every boundary**
- Validating format but not enforcing type safety; **"123" is a valid string but not a valid 32-bit integer if out of range**
- Performing validation in client-side only; **always validate server-side; client validation is for UX, not security**
- Trying to sanitize input for multiple contexts; **validate once, encode once per context (HTML context gets HTML encoding, SQL context gets parameterized queries, etc.)**

## Further Reading

- OWASP Input Validation Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
- OWASP Deserialization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html
- NIST SP 800-53 (SI-10 Information System Monitoring): Input validation requirements
- Semantic Exploitation (research on flaws in validation logic): https://cs.umass.edu/~amir/papers/semex.pdf