How do you keep a negative test from passing without proving the control works?

## The failure this question is about Negative tests pass by default. Anything that stops the operation from succeeding turns the test green, and most of those things have nothing to do with your control. This is the security-testing equivalent of a test that asserts nothing, and it is worse than no test, because a green suite is read as coverage and the threat gets marked handled. The ways a negative test passes vacuously, roughly in order of how often they happen: - **The target does not exist.** The abuse case is "read someone else's document" but the fixture never created that document, so the attempt gets a not-found and the test is green against an empty database. - **The attempt was malformed.** A schema or type error rejects the request before it ever reaches the authorization check. - **The environment is broken.** A missing configuration value produces a server error on every call, and the assertion "not successful" is satisfied by a service that is simply down. - **The fixture principal is wrong.** The test authenticates as nobody, or as a user with no roles at all, so a coarse gate refuses it long before the specific control you meant to test runs. - **The wrong control did the work.** A rate limiter, a proxy rule, or a request-size cap refused it, and the authorization logic you believed you were exercising was never invoked. ## Worked case — an e-signature envelope A document e-signature service. Abuse case: an authenticated user of the service holds a signing link addressed to a different recipient and walks it to open the envelope. The asset is non-repudiation and audit truth — who signed what, and the ability to prove it later. A weak test authenticates as some user, requests the envelope, and asserts the response was not a success. It goes green in an environment where the envelope was never created, and it stays green if the authorization check is deleted next sprint. A strong test does four things: 1. **Seeds the envelope and proves it.** The rightful recipient opens it successfully in the same test run. This is the positive control, and it kills the empty-database class of vacuous pass in one line. 2. **Asserts the specified refusal.** Whatever the design chose — an explicit forbidden response with a documented error code, or a deliberate not-found to avoid disclosing that the envelope exists — the test asserts *that* decision, so a change in behaviour is a test failure and a design conversation rather than a silent drift. 3. **Asserts the invariant and the evidence.** The envelope is still unopened, no signature is recorded against it, and the audit log contains a denial event naming the attempting principal and the envelope. For this asset the audit assertion is not optional garnish: an unrecorded denial is itself a finding. 4. **Is proven to be able to fail.** Disable or remove the authorization check locally and run it; it must go red. This is a one-off manual verification, cheap and decisive, and it is the answer interviewers are listening for. ## Assert the design's decision, not your preference Candidates often insist the response must be a forbidden status. Sometimes the design deliberately returns not-found so an unauthorised caller cannot learn that a resource exists. Both are legitimate; the test's job is to encode whichever one the model decided, together with the compensating assertions — unchanged state and a denial record — that stop the ambiguous status from hiding a real failure. What is never acceptable is treating a server error as proof the attack was blocked. A crash is an availability finding, not a passing control. ## Brittleness, the opposite mistake Over-correcting produces tests that assert exact message strings, response ordering, or internal identifiers. Those fail on copy edits and teach the team to ignore the negative suite, which is a slower path to the same place. Assert status plus a stable machine-readable error code, plus state and evidence. That is specific enough to catch a regression and stable enough to survive a refactor. ## One environment is not enough A negative test that holds in one place can fail in another, because the thing that re-opens the threat is frequently configuration rather than code — a permissive setting, a stale policy binding, a feature flag left on. A multi-region loyalty API makes the point: the assertion "a member cannot read another member's points ledger" is written once and then run against every region and every environment as a standing check. Same test, many places, because that is where the drift lives. ## What to say in an interview Name the vacuous-pass classes, describe the positive control, describe asserting the specified refusal plus invariant plus evidence, and finish with the guard-removal check. Mentioning that you have personally seen a negative suite go green against an empty database is the detail that reads as lived experience.