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

1. Define schemas

- Prefer typed schemas (DTOs) and allow-lists - Enforce length, charset, ranges, and required fields

1. Canonicalize early

- Normalize encoding, trim, and apply consistent parsing (dates, IDs, enums)

1. Validate before use

- Reject unknown fields if possible - Ensure IDs map to authorized resources (ownership/tenant checks)

1. Protect sinks

- Parameterize DB queries - Avoid dynamic execution (eval, shell, template injection)

1. 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.