The invisible specification

Every workflow contains assumptions: a coupon is used once, a refund follows payment, a verified email stays verified, or a quantity is positive. When those rules live only in conversation, the implementation protects the happy path and leaves unusual states undefined.

Logic vulnerabilities arise when an attacker finds a sequence the designers did not model. Each request can be syntactically valid and still violate the business invariant across time.

Write abuse stories beside user stories

For each valuable action, ask what happens if it is repeated, reordered, interrupted, run concurrently, or performed from another account. Include negative numbers, boundary values, stale tokens, and objects that change owner mid-flow.

Document the invariant at the service boundary and enforce it transactionally where possible. A front-end stepper is not a state machine; a direct API caller can skip every visual stage.

  • Repeat one-time actions and replay previous requests.
  • Change server-relevant values after the UI validates them.
  • Run the same transition concurrently from two sessions.
  • Interrupt a multi-step flow and resume it in a different state.

Automation needs a human model

Automated scanners are excellent at repeatable technical checks, but they cannot infer every commercial or domain rule. Give testers a clear data-flow diagram, role model, and statement of expected transitions.

When a logic flaw is found, fix the violated invariant and add a regression scenario—not only the one endpoint that exposed it. Similar assumptions often repeat across a product.

← Back to the archive