Abuse case testing: write tests from an attacker's view

Abuse case testing starts from a simple idea: before you build a feature, write down how someone could misuse it, then make each of those misuses a test. It answers a common problem. Security requirements often read "the application must be secure" or "the app must defend against the OWASP Top 10." Nobody can build or test against that. This guide follows the OWASP Abuse Case Cheat Sheet, and is honest about where OWASP itself now stands on it.

From workshop to test. Simplified from the OWASP Abuse Case Cheat Sheet.

What an abuse case is

OWASP defines an abuse case as a way to use a feature that its builder did not expect, which lets an attacker influence the feature or its outcome through their actions or input.

The cheat sheet sees two uses for them. First, they help you discover attacks, by asking "what can go wrong?" for each feature. Second, they record those attacks in a form developers find less intimidating than a formal risk register.

Abuse cases come in two kinds, and OWASP says to mark each one:

• Technical: for example, putting a cross-site scripting payload into a comment field.
• Business: for example, changing the price of an item in an online shop before placing the order, so the buyer pays less.

The business kind is the one scanners miss. No tool knows that your prices should not be editable from the browser.

A method OWASP now calls historical

Before you adopt it, know this: OWASP has marked the Abuse Case Cheat Sheet as historical. Its reviewers found abuse cases are rarely used in practice, and that the material reads more like a getting-started tutorial than a cheat sheet. The sheet itself says the full framework seems heavyweight, with few published examples or success stories.

There is another view in the same sheet. It quotes OWASP's software assurance maturity model, which lists misuse and abuse cases as a practice for teams maturing their security testing, and describes them as fuel for finding concrete security tests. The cheat sheet also points to threat modeling as the wider technique: each item on a threat model's "what are we going to do about it" list can become an abuse case your engineers can act on.

So treat it as a lightweight bridge between a threat model and your test suite, not as a process to adopt whole. Our post on threat modeling for a small team covers the step before.

Abuse case testing starts with a workshop

The cheat sheet suggests a workshop for the features planned in a sprint or project. About 4 hours is a good start, depending on the feature list. The people in the room:

• A business analyst who explains each feature from the business side.
• A risk analyst who judges the business risk of each proposed attack.
• A penetration tester who proposes attacks. OWASP suggests two with different backgrounds if you can, or an outside specialist if you have none.
• Technical leads who discuss attacks and fixes.
• A QA analyst or functional tester who knows how the feature should work, should not work, and what makes it fail.

For each feature, the business side explains it, the testers propose attacks, a security person proposes a countermeasure and where it belongs (design, code, network, infrastructure), and the technical leads say whether it is feasible. Then the group agrees which cases to address, and writes down why for any risk it accepts.

If you have no penetration tester, OWASP lists sources for attacks to consider: OWASP's Automated Threats to Web Applications, the OWASP Testing Guide, and the CAPEC catalogue of attack patterns.

Write each case down with an ID

OWASP's tracking sheet has three tabs: features, abuse cases and countermeasures. Each abuse case gets a unique ID, such as ABUSE_CASE_001, and these columns:

• The feature it affects
• A description of the attack, and a reference to a catalogue entry if one exists
• A business risk rating
• A severity score, if the case involves a specific vulnerability
• Technical or business
• The countermeasure that applies
• The decision: address it, or accept the risk

One detail matters: keep business risk and severity apart. The sheet notes that a CVSS score measures how severe a vulnerability is and should not be used alone to judge risk. Record your business risk rating and its reasons separately, and never adjust a CVSS score to stand in for business risk.

Turn cases into acceptance criteria

An abuse case on a spreadsheet changes nothing. After the workshop, OWASP says, each case the team chose to address becomes a security requirement in the feature's specification, or an acceptance criterion in its user story. That is what makes the work visible: it gets estimated, built and checked like any other requirement.

In agile teams, the cheat sheet places the workshop after the stories are chosen for the sprint, so the abuse cases describe work that is actually planned.

Tag the code and test every case

During the build, OWASP suggests marking where each case is handled. In designs and diagrams, note which case IDs they address. In code, add a comment or annotation listing the case IDs. A small script can then show where each case is covered and which are not.

Then validate. The cheat sheet lists:

• Automated: security unit, integration or functional tests, and custom rules in static or dynamic scanners, run in continuous integration at each commit, daily or weekly.
• Manual: peer secure code review, and handing the full list to penetration testers so they confirm each attack no longer works and look for new ones.

The automated tests pay off later. OWASP notes they catch a countermeasure that was removed or switched off during maintenance or a bug fix.

Worked example: abuse cases for a checkout

Say your sprint adds a checkout with a discount code field.

1. Workshop (1 hour for this feature). The product owner walks through checkout. The tester proposes: change the price in the request; apply one discount code many times; apply a code meant for another account; send a script in the delivery note field.
2. Record. ABUSE_CASE_001 price change (business, high), 002 repeated code (business, medium), 003 another account's code (business, medium), 004 script in the note (technical, medium).
3. Decide. Address 001 to 004. Countermeasures: the server reads prices from the catalogue, never the request; codes are checked and used up on the server; notes are encoded on output.
4. Acceptance criteria. "Given a request with a changed price, the order total uses the catalogue price." One line per case.
5. Tests. Write one integration test per case, tagged with its ID, and run them in continuous integration.
6. Before release. Give the list to whoever runs your penetration test.

Frequently asked questions

Is abuse case testing still recommended by OWASP?

OWASP has marked its Abuse Case Cheat Sheet historical because abuse cases are rarely used in practice. Its maturity model still lists misuse and abuse cases as a source of concrete security tests.

How is an abuse case different from a threat model?

Threat modeling is the wider set of techniques for finding what can go wrong. An abuse case records one specific misuse of one feature, in a form that can become a requirement and a test.

Do I need a penetration tester in the workshop?

It helps, but OWASP lists alternatives: its Automated Threats list, the OWASP Testing Guide and the CAPEC attack patterns.

Get started

Pick one feature in your current sprint and write three ways it could be misused. Turn the worst one into a test this week.

whitehatstoic's cybersecurity and AI safety testing includes a web app and API review, a written report with fixes, and a retest after you apply them, scoped after a short call. No test finds every weakness, but an outside tester brings attacks your own team may not think of. Our checklist to prepare for a penetration test shows what to hand over.

Building something that has to be safe? Book a meeting with whitehatstoic: tell us the product, the deadline and your biggest worry, and we reply with a plan and a price.