When applying fail fast, what is the difference between an assertion, a precondition guard, and validation of untrusted external input - and why is it dangerous to enforce a security rule with an assertion?

## Three checks that look alike and behave differently All three stop execution on a bad value, so they are easy to conflate. They differ in **who made the mistake**, **whether the check is guaranteed to run**, and **what should happen next**. ### 1. Assertion - "this should be impossible" An assertion documents an internal assumption: a loop invariant, an unreachable branch, a state that no legal sequence of calls should produce. Its audience is the developer. Key properties: - **Removable.** Many platforms strip or disable assertions in production builds: Java's `assert` only runs with the `-ea` flag, which is off by default; C/C++ `assert` is compiled away when `NDEBUG` is defined; Python's `assert` disappears under `-O`. Therefore an assertion is never a guarantee. - **Must be side-effect free.** `assert queue.pop() != null` changes behaviour depending on whether assertions are enabled - a nightmare bug class. - **Never for untrusted input.** If it can be triggered by a user, it is not an assertion; it is validation. ### 2. Precondition guard - "the caller broke the contract" A guard enforces the documented requirements of a function on its arguments or the receiver's state. Its audience is also a developer, but it **always runs**, in every build. - Signals a *programming error*: an argument out of range, a null where the contract says non-null, a method called in the wrong lifecycle state. - Should throw a distinct, specific error type (argument error, illegal state) with the parameter name and the offending value. - Callers should generally **not** catch it. Catching and retrying a programming error just hides the bug; the correct fix is in the calling code. - Placed at the top of the function, before any mutation, so failure leaves nothing half-done. ### 3. Validation of untrusted input - "bad data is expected here" At a trust boundary - HTTP request, message payload, uploaded file, config file, another team's API - malformed data is not a bug, it is a normal occurrence. Properties: - **Always on**, no exceptions, and part of the security perimeter. - Produces *domain* or *field-level* errors that are safe to show a client, and maps to a client-error status (a 4xx), never an internal-error status. - Usually **aggregates**: report all bad fields at once rather than one per round trip. - Should be **allow-list** shaped (accept only what matches the expected shape) rather than deny-list shaped. - After validation, convert the data into trusted domain types so inner layers do not re-validate. ## Why assertion-as-security-control is a genuine vulnerability Suppose an authorisation check or a bounds check is written as an assertion. In development, assertions are enabled and everything looks safe; every test passes. In production, assertions are disabled for performance - and the check simply is not there. The hardened build is the *weakest* build. The same trap applies to input length or index bounds checks: with assertions off, the code proceeds into the memory or logic the check was protecting. A second, subtler failure: because assertions may be disabled, developers get sloppy about their cost and put expensive or effectful expressions inside them, producing behaviour that differs between environments - the hardest kind of bug to reproduce. **Rule of thumb:** if a real user, a network peer, or an attacker can cause the condition to be false, it must be a guard or validation, never an assertion. ## Choosing between them Ask: *whose mistake is this, and can it happen in production?* - External actor, expected in production -> **validation**, always on, client-facing error, aggregate results. - Another developer calling my function wrongly -> **guard**, always on, programmer-facing error, do not catch. - Nobody should ever be able to cause this; it means my own logic is broken -> **assertion**, optional at runtime, side-effect free, also a documentation device. ## Related nuance - **Where to put the boundary.** Validating untrusted input in one clearly identified layer keeps inner code free of paranoia. Scattering half-validation everywhere gives neither the guarantee nor the simplicity. - **Defensive versus offensive programming.** Defensive code tries to survive bad input (substituting defaults, clamping values). Offensive programming - the fail-fast stance - deliberately refuses, on the grounds that a silently clamped value produces wrong answers that nobody will investigate. Use defensive substitution only where the fallback is genuinely correct behaviour, not to hide a defect. - **Static enforcement beats all three.** A non-null type or a range-checked value type removes the whole question by making the illegal call fail at compile time.