Missing Input Validation

Missing input validation is the failure to verify that data entering a system — request bodies, query parameters, headers, file uploads, message payloads — matches what the application expects before acting on it. Unvalidated input is the root cause behind most injection vulnerabilities, data corruption, and many denial-of-service conditions.

Why It Happens

Validation is tedious boilerplate that does not add visible features, so it gets deprioritized. Developers assume the front end already validated the data, forgetting that any client can be bypassed. APIs evolve and new fields slip in without rules. The "happy path" works in testing with well-formed input, hiding the gaps that only malicious or malformed input reveals.

Why It Hurts

Without validation, hostile input flows straight into queries (SQL/NoSQL/command injection), templates (XSS, SSTI), file paths (traversal), and serializers. Oversized or deeply nested payloads exhaust memory and CPU, causing denial of service. Wrong types and out-of-range values corrupt data and trigger crashes or subtle logic errors. Because the boundary is unguarded, every downstream component must defend itself, and one that fails to compromises the whole system.

Warning Signs

• Handlers read request fields and use them without checks.
• No maximum length, count, or size limits on inputs and uploads.
• The system trusts client-supplied Content-Type, IDs, or flags.
• Errors deep in the stack are caused by malformed input that reached business logic.

Better Alternatives

Validate at the trust boundary using an allowlist approach: define exactly what is acceptable (type, format, range, length, enum) and reject everything else, rather than trying to blocklist bad values. Use declarative schema validation (JSON Schema, Zod, Pydantic, Bean Validation, protobuf) so rules are explicit, consistent, and testable. Enforce size and depth limits to bound resource use. Fail closed: when input is invalid, reject with a clear error rather than guessing intent. Treat validation as separate from, and in addition to, context-specific output encoding.

How to Refactor Out of It

1. Map every entry point where external data enters the system.
2. Define a schema for each, specifying allowed types, formats, ranges, lengths, and required fields.
3. Apply validation as early as possible, centralized in middleware or the deserialization layer.
4. Add explicit limits on payload size, array length, and nesting depth.
5. Ensure invalid input is rejected (fail closed) with safe, non-leaking error messages.
6. Add tests with malformed, oversized, and boundary inputs to lock in the behavior.