You own a public API that must accept free-text fields, arbitrary JSON documents and file uploads. Design the validation strategy: what fails closed, which layers exist, and how do you stop the validation code from becoming a vulnerability in its own right?

## Start from what fails closed A validation strategy is a set of decisions about what happens to input nobody anticipated. Design it as layers, each with a stated failure mode. ### Layer 0 — resource limits, enforced before and during parsing This layer is special because **nothing downstream can compensate for it**. No amount of parameterisation or context-correct output handling makes a four-gigabyte body, a million-element array or a thousand-level-deep document safe. Enforce: - maximum request bytes, and a maximum per part for multipart; - allowed content types, with the server choosing the parser rather than the client's declaration choosing it; - maximum nesting depth, member count, array length and individual string length; - decompression ratio and absolute expansion budget for any compressed or expandable format; - a total time budget for parsing. Crucially these must be enforced **while streaming**, not by parsing the document and then measuring it — measuring afterwards means the attack already succeeded. ### Layer 1 — one schema, one parse Declare the contract once, declaratively, and compile it into every entry point: the HTTP handler, the message consumer, the batch import, the administrative tool. Two hand-written validators over the same payload is how parser differentials are born, and any component that re-parses independently is a standing risk. The live decision here is **unknown fields**. Ignoring them silently hides client bugs and enables mass assignment when a later binding layer does consume them; rejecting them is the closed-world choice and gives clients an immediate, honest error, at the cost of forward compatibility for clients that add fields optimistically. The defensible position is: reject on endpoints where fields drive authorisation, pricing, state or identity, and version the schema so clients have a supported path to add fields. ### Layer 2 — the domain Types, ranges, formats, cross-field consistency, legal state transitions. This lives inside the service because only the service knows it. It is also where enumerated maps belong: any field that selects structure — a sort column, a template, a redirect target, a report type — resolves through a finite, code-owned map rather than a character pattern, because a pattern is open-world with respect to which value it admits. ### Layer 3 — free text Accept it. Check that the encoding is well-formed (valid UTF-8, no unpaired surrogates, control characters excluded unless meaningful) and bound the length, then store exactly what the user typed. Do not strip, do not "clean", do not replace. Stripping corrupts legitimate data, produces false confidence, and a removal step can synthesise the token it removes when the input is crafted so the remainder becomes adjacent. Every sink applies its own context-correct control at the point of use. If the product truly requires rich markup, the control is to parse the input with a real parser and re-serialise from a strict structural model, discarding anything not in the permitted set — a parse-and-rebuild, never a pattern filter. That is a sink-side transformation, and it should be applied once, at a defined layer, with its output treated as the canonical stored form. ### Layer 4 — files The client's declared type and the file extension are claims. Identity comes from **parsing**: decode the file with a hardened, bounded parser and, where the format allows, transcode and re-encode it, discarding metadata. Store under a name the code generated, never one the client supplied. Serve from a separate origin with a fixed content type and no sniffing. Bound decompression for archives, and check entry names and entry sizes before extraction. Magic-byte sniffing alone is not identification — polyglot files satisfy two formats at once. ## The validator as attack surface This is the part most candidates never reach, and it is what the question is really probing. - **Catastrophic backtracking.** A pattern with nested quantifiers over attacker-controlled length can take exponential time — a denial of service delivered *by the security control*. Mitigations: bound length before matching, anchor patterns, avoid nested quantifiers and ambiguous alternation, prefer a linear-time engine, and enforce a matching timeout. - **XML and schema processing.** Validators that resolve external entities or DTDs turn the check into a file-read and outbound-request primitive; validators that fetch remote schemas by URL turn it into a server-side request primitive with the server's network position. - **Unbounded canonicalisation.** Normalisation and decompression during the canonicalisation step can expand input dramatically. Budget it like any other parse. - **Error handling.** Never echo the invalid input back verbatim — that is a reflection sink. Never leak internal identifiers, stack traces or schema internals. Use uniform errors where a distinguishable message would reveal the existence of a resource or an account. - **Logging.** A validator that writes rejected input into logs feeds it to a whole downstream stack — log processors, dashboards, alerting. Encode or bound what you log. ## Failure behaviour **Reject; never coerce.** Silent truncation is the classic self-inflicted differential: the validated value and the stored value differ, and the two systems now disagree — a length limit applied after the check is the standard instance. Silent type coercion (a string accepted where a number was declared, a number rounded) hides client bugs and produces values nobody validated. Return a stable, machine-readable error naming the field and the rule, and apply nothing partially — an entire request either takes effect or does not. ## Operating it Emit a counter per rule. A rule that fires constantly is either wrong, poorly documented, or under attack, and each of those is worth knowing. This is where denylists earn their keep: as detection signals — the bottom rung of the ladder — never as the control in the request path. ## The one-sentence position Validation is strict where it is the *only* control — resource bounds and the domain model — permissive and non-mutating where the domain is genuinely open, and never the thing standing between an attacker and a sink; the sink owns its own safety.