Security Requirements and Abuse Cases

Making security testable

'The app must be secure' cannot be tested. A security requirement must be specific and verifiable, for example: passwords are hashed with a slow, salted algorithm such as Argon2id or bcrypt, or every API endpoint except /health requires a valid access token. A good source is the OWASP Application Security Verification Standard (ASVS), a catalogue of requirements grouped by area (authentication, session management, access control, input handling and more) and by level, from basic hygiene to high-assurance systems. Teams pick a level and turn relevant items into acceptance criteria. Alongside user stories, write abuse cases: As an attacker, I want to reuse a stolen session cookie so that I can act as another user. Each abuse case suggests a control and a test. Requirements written this way flow naturally into automated tests that run in CI, which is exactly where DevSecOps wants them.

An abuse case becomes a test

A minimal check that a protected handler rejects missing and wrong tokens. In a real project this lives in your test suite and runs on every pull request.

def get_invoice(headers):
    token = headers.get("Authorization", "")
    if token != "Bearer valid-token":
        return 401
    return 200

cases = {"no token": {}, "wrong token": {"Authorization": "Bearer stolen"},
         "valid": {"Authorization": "Bearer valid-token"}}
for name, h in cases.items():
    print(f"{name:<12} -> {get_invoice(h)}")

Output:

no token     -> 401
wrong token  -> 401
valid        -> 200

Write the negative test

Most test suites check that the right user can do something. Security bugs hide in the missing test that the wrong user cannot. Add one negative test per authorisation rule.

त्वरित जाँच: Which of these is a well-formed security requirement?

• The system should be very secure
• We will follow best practices
• Hackers must not get in
• All endpoints except /health reject requests without a valid access token with HTTP 401