How do you restate the mitigation note "validate the uploaded XML" as a testable requirement?

### Why "validate the uploaded XML" is not yet a requirement The note is a **mitigation intention**. It has no subject you can point at, no condition, and no outcome you could observe, so there is no input that makes it fail. Anything unfalsifiable is untestable, and anything untestable will be marked done by whoever is in a hurry. Words that signal this failure: *properly, securely, appropriately, robustly, as needed, where applicable, harden, sanitise*. If the sentence survives having the word "properly" deleted with no loss of meaning, the word was doing all the work. Keep the four artifacts distinct while you rewrite: | Artifact | What it says | | --- | --- | | Threat | An anonymous uploader submits a crafted document and reads a file from the server | | Weakness | The parser resolves external entities in untrusted input | | Control | Parse with entity resolution and DTD processing off | | Verification requirement | A testable sentence proving the control is present in this build | ### The shape of a verification requirement Three parts, and a published catalog will have all three: 1. **Component** — which service or entry point. Not "the system". 2. **Condition** — the circumstance under which the behaviour must hold, including the adversarial one. 3. **Observable outcome** — what an observer sees. A rejection, a status code, a log record, an absent side effect. Applied to the upload: > Verify that the invoice-ingest service parses uploaded XML with DTD processing and external > entity resolution disabled, rejects any document containing a DOCTYPE declaration with a 400 > response, and writes the rejection to the audit log with the submitting IP and document hash. Now a tester knows exactly what to send and exactly what to look for, and a reviewer can read the parser configuration and say yes or no. Notice what the rewrite forced out into the open that the original hid: the *enforcement point* (server side, in the ingest service, not in a browser-side check), the *default* (reject rather than best-effort clean-up), and the *evidence* (a log line, so an attempt is visible even though it failed). ### Check the catalog before writing prose ASVS already contains requirements for parsing untrusted structured data, and using its wording has three advantages over inventing your own. The phrasing is already testable, so you inherit the discipline. The requirement carries a **verification level**, which tells you whether meeting it is part of your baseline or an above-baseline commitment. And it usually carries a CWE mapping, so the identifier work is done. Write your own only when nothing matches — and then write it in the same shape, so a reader cannot tell which requirements came from the catalog and which from you. ### What the CWE tag adds Tag this one **CWE-611, Improper Restriction of XML External Entity Reference**. That number is not bureaucracy; it is the join key. Three separate teams — the person who found the threat, the person who wrote the verification requirement, the person who later writes a detection or code-review rule — now refer to the same weakness class without having read each other's documents. And when the same weakness appears in the export service and the partner feed, the backlog shows one weakness with three instances rather than three unrelated tickets, which changes the fix from three patches to one hardened parser factory that every service uses. Two cautions on the tagging. First, tag the **weakness**, not the attack story: a single CWE can be reached through many routes, and one route can involve several weaknesses. Second, a CWE is a name, not a rating: it carries no severity, no deadline and no evidence that anything was fixed. ### Where this sits in the STRIDE flow The modeled threat here is **information disclosure** — the external entity makes the parser fetch a local file and return its contents in an error or a response field — which violates **confidentiality**. The asset is not customer data at all: it is internal file contents and whatever credentials the process can read from disk. Naming the asset that way matters, because it is what justifies a rejection-by-default requirement rather than a filtering one, and it explains why "block dangerous entities" is a weaker requirement than "resolve no entities at all": a denylist has to be right every time, a disabled feature has to be right once. ### A senior habit After rewriting, read the requirement back and ask: *what input makes this fail, and can I write it in one line?* For the version above, the answer is immediate — a document with a DOCTYPE and an external entity referencing a local path must come back 400 with a log entry. If you cannot answer that question, you have written a wish in the register of a requirement, and the difference will only surface at the point where someone claims the mitigation is in place and nobody can check.