Input Validation Hardening

When to use

Use this skill when asked to validate inputs, harden request parsing, or prevent injection/abuse.

Inputs to collect (if available)

• Entry points (HTTP endpoints, consumers, file parsers)
• Data sensitivity and trust boundaries
• Existing validation libraries/patterns in the codebase
• Known attack/abuse cases (payloads, bypass attempts)

Step-by-step process

1. Inventory inputs
   • HTTP params/body/headers, file uploads, message payloads, env vars, CLI args
2. Define schemas
   • Prefer typed schemas (DTOs) and allow-lists
   • Enforce length, charset, ranges, and required fields
3. Canonicalize early
   • Normalize encoding, trim, and apply consistent parsing (dates, IDs, enums)
4. Validate before use
   • Reject unknown fields if possible
   • Ensure IDs map to authorized resources (ownership/tenant checks)
5. Protect sinks
   • Parameterize DB queries
   • Avoid dynamic execution (eval, shell, template injection)
6. Add tests
   • Boundary tests (min/max), malformed inputs, and common payloads

Output

• Proposed schema(s)
• Where to enforce validation (middleware/controller boundary)
• Tests added/updated

Repo integration (optional)

Related prompts:

• validate-input-handling.prompt.md
• scan-for-insecure-apis.prompt.md

Output format

• Inventory: inputs and boundaries
• Proposed schema(s) (high-level)
• Enforcement point: where validation should occur
• Test plan: boundary + malicious inputs

Examples

• “Public JSON API” → reject unknown fields, enforce max sizes, and add negative tests for type confusion and oversized payloads.