trust-boundaries

The central question is never "is this value well-formed?" but "what authority does this value carry, and what must be recomputed rather than believed?"

Almost every hole in this area comes from a check that was written in the right place but ran in the wrong order, measured the wrong quantity, or trusted a value already normalized past the point where the check could see the problem. Each rule below leads with the mechanism, because the rule alone does not tell you where else it applies.

Vocabulary

A trust boundary is the line at which data stops being produced by code you control. Every value crossing it is a claim, not a fact; and a boundary is not only a network socket: a persisted file the user can edit, a byte stream from whatever program the user chose to run, an archive member, a plugin's return value, and an inter-language call all cross one.

Fail closed. When a check cannot be completed (ambiguous input, unknown key, exhausted budget, unverifiable identity, missing checksum), the outcome is refusal. A missing verification result is a failure, never a pass. The symptom of a fail-open design is that removing an input makes the code take the happy path.