Skynet just published an article: CWE-20: Improper Input Validation — When Bad Data Becomes Dangerous Behavior – 7312.us and here’s my review of it.

What the Author Gets Right

The framing is strong and correct: improper input validation is rarely the final vulnerability — it’s the enabling condition for many others (injection, traversal, deserialization, DoS, logic abuse). The article gets this priority right at the top and returns to it at the close, which is good pedagogy.

The taxonomy of why developers get this wrong is accurate and well-chosen. Validating only for the “happy path,” validating too late in the request lifecycle, relying on client-side validation, blacklist filtering instead of allowlists, and forgetting semantic validation (the “transfer -1000” example is exactly the right illustration) are all real and persistent root causes. The point that syntactically valid input can still be semantically invalid is one developers genuinely miss, and the article surfaces it clearly.

The modern exploitation section is more sophisticated than most introductory CWE write-ups. Naming parser differential abuse, canonicalization bypass, and validation chaining failures shows the author understands that input validation bugs in 2026 rarely look like “user typed <script>.” Parser differentials in particular — where a validator and a downstream consumer disagree about what an input means — are behind a large share of real CVEs (HTTP request smuggling, JSON interoperability bugs, JWT confusion attacks), and acknowledging them raises the article above the usual material.

The mitigation guidance is largely correct: prefer allowlists over blocklists, validate early, normalize before validating, validate semantics in addition to syntax, re-validate at trust boundaries, fuzz the validation layer, and treat headers, cookies, queues, and internal APIs as input sources too. That last point — that “input” extends well beyond form fields — is one many developers haven’t internalized.

The allowlist regex example (^[A-Za-z0-9]{1,32}$) is a faithful illustration of positive validation, and the “Structured Validation” recommendation to use schema libraries is the right modern answer.

What the Author Gets Wrong or Glosses Over

The opening example is poorly chosen. The age = int(...); discount = 100 / age snippet illustrates a divide-by-zero crash, not a security vulnerability in the CWE-20 sense. CWE-20 is a meta-weakness — its danger is that it enables other weaknesses (SQLi, XSS, SSRF, path traversal, deserialization, integer overflow). Leading with a crash example understates the severity and confuses readers about why this CWE is consistently in the top tier of the CWE Top 25.

Validation and sanitization/encoding are conflated. The article never draws the critical distinction between validating input (deciding whether to accept it) and contextually encoding or escaping it (making it safe for a specific sink — SQL, HTML, shell, LDAP, OS command). This matters because validation alone does not prevent injection — parameterized queries and context-aware output encoding do. A reader could finish this article believing that good allowlist validation is sufficient to prevent SQL injection. It isn’t.

The “Safer” page example is incomplete. The snippet shows allowedPages.includes(page) but never actually uses the validated value or rejects with a clear error. More importantly, it doesn’t show the most common real-world failure mode: validating one representation of the input and then using a different representation downstream (the canonicalization point is mentioned abstractly but never demonstrated).

No discussion of where to validate in layered architectures. Modern apps have multiple layers — API gateway, controller, service, repository — and authors rarely address the question of which layer owns validation, or how to avoid the trap of “everyone assumes someone else validated it.” The article hints at this with “re-validate at trust boundaries” but never operationalizes it.

Schema validation gets one line. In 2026, the practical answer for most applications is a schema library (Pydantic, Zod, JSON Schema, Joi, protobuf, OpenAPI request validation). This deserves more than a passing mention because it’s the realistic path most teams will take, and there are real pitfalls — coercion-on-by-default, additional-properties-allowed-by-default, schema/code drift — that the article doesn’t warn about.

Trust boundary discussion is shallow. The article says to re-validate at trust boundaries but never defines what one is. A trust boundary is any point where data crosses from a less-trusted context to a more-trusted one (network → application, frontend → backend, public service → internal service, user → database, external API response → application logic). Naming the concept without defining it leaves the most useful idea in the article underexplained.

No mention of size and rate limits as validation. Input validation isn’t only about content — it’s about bounding the cost of processing input. Maximum body size, maximum array length, maximum string length, maximum JSON nesting depth, maximum regex backtracking (ReDoS), upload size and count caps — all of these are input validation and all are absent.

The “Visual” sections are broken. Lines like 1. User InputMalformed / Malicious2. Weak Validation... are clearly diagrams whose layout collapsed. They convey nothing as currently rendered.

No reference to CWE-20’s relationship with other CWEs. CWE-20 is a parent or contributing factor to CWE-89 (SQLi), CWE-78 (OS command injection), CWE-79 (XSS), CWE-22 (path traversal), CWE-94 (code injection), CWE-502 (deserialization), and many more. Showing that map would help readers understand why this weakness sits near the top of every CWE Top 25 list.

Recommendations for Developers

Beyond what the article covers, the most useful additions:

Separate validation from sanitization in your mental model. Validation rejects bad input at the boundary. Sanitization/encoding makes safe input safe in a specific sink. Both are needed; neither substitutes for the other. For SQL, the answer is parameterized queries, not “I validated the input.” For HTML output, the answer is context-aware encoding by your templating engine. For shell, the answer is execve-style argument arrays, not string concatenation after a regex check.

Use schema validation, but configure it carefully. Pydantic, Zod, JSON Schema, Joi, FastAPI request models — pick one and apply it at the edge of every service. Watch for default behaviors that work against you: implicit type coercion (a string "7" silently becoming 7), additionalProperties: true allowing unexpected fields through, optional fields treated as nullable, and silent truncation of long strings. Make schemas strict by default and document each loosening.

Validate at the trust boundary, then trust within the boundary. Every request entering your service should pass through a single, documented validation layer (typically a request DTO or schema bound at the controller). Inside the service, downstream code should be able to assume validated types. When data crosses into another service, validate again at that boundary — never assume the previous hop’s validation persisted intact through serialization, transport, and deserialization.

Bound resource consumption as part of validation. Set explicit limits on request body size, JSON depth, array length, string length, number of file uploads, file size per upload, total request count per connection. Audit your regular expressions for catastrophic backtracking (ReDoS) — use linear-time engines (RE2) for any regex applied to user input, or test with adversarial inputs.

Canonicalize once, validate after, and never decode twice. Decode URL-encoding, unicode-normalize, resolve relative paths, and apply case folding before validation. Then never re-decode. Most canonicalization bypasses come from validation happening on one representation and use happening on another.

Treat every input source as untrusted, not just user forms. HTTP headers (especially Host, X-Forwarded-For, Content-Type), cookies, query strings, path parameters, request bodies, file uploads (content, filename, MIME type, magic bytes), message queue payloads, webhook callbacks, responses from external APIs, environment variables in containerized contexts, and database fields populated by other systems — all are input and all need validation at the point of consumption.

Fuzz the validator itself. Property-based testing (Hypothesis for Python, fast-check for JS, QuickCheck for Haskell) and structure-aware fuzzers (LibFuzzer, AFL++, restler-fuzzer for APIs) routinely find inputs that validators accept but downstream consumers mishandle. If your service has an OpenAPI spec, run an API fuzzer against it; the parser differential bugs the article mentions are exactly what those tools find.

Log rejections, not raw payloads. When validation rejects input, log the rule that failed and structured metadata (endpoint, source IP, user, rule name). Do not log the full payload unredacted — attackers will deliberately submit secrets and PII to weaponize your logs, and large or binary payloads can themselves be a log-pipeline DoS vector.

Connect validation to your threat model. For every input field, write down: what type is it, what range or pattern is valid, what sinks does it reach (SQL? shell? filesystem? template? external API? LLM prompt?), and what would an attacker want to do with it. That table is the source of truth for both validation rules and the encoding/escaping needed at each sink. If you can’t fill it in, the field isn’t safely handled regardless of what your validation library says.

CWE-20: Improper Input Validation — When Bad Data Becomes Dangerous Behavior