An abuse case describes a way to use a feature that the implementer did not expect. Write it as an attacker story against one specific feature, give it an ID, rate it, and link it to a countermeasure and a test. The OWASP Abuse Case Cheat Sheet lays out a workshop process for doing this.
One caveat first: the cheat sheet is marked archived, and its reviewers note that abuse cases are rarely used in practice. That is a fair warning. The lightweight version below is the part worth keeping.
What a good abuse case looks like
OWASP defines it as "a way to use a feature that was not expected by the implementer". It suggests user story style, such as "As an attacker, I..." statements. Each case should target a specific feature. The page's example is uploading an Office file with a malicious macro.
Cases come in two kinds. Technical ones involve things like injection in a comment field. Business ones involve logic abuse, such as altering an item's price before checkout.
Fields to record
- A unique ID so the case can be tracked.
- The feature it applies to.
- A reference to a known attack pattern, if one exists.
- Business risk rating.
- Kind: technical or business.
- Linked countermeasure.
- Decision: to address, or risk accepted with a reason.
A light workshop
The cheat sheet suggests a four hour workshop with business analysts, risk analysts, penetration testers, technical leads and QA. Most teams can start smaller. A one hour version with a developer, a tester, a product owner and a security contact still works.
For each feature:
- The product owner explains it in plain words.
- Others propose attacks. Ask "how could I make this do something unfair or harmful?"
- Someone proposes countermeasures and where they belong: design, code, infrastructure or network.
- A developer says how hard each is.
- The group rates business risk and decides which to address.
Keep CVSS out of the rating
The cheat sheet notes that CVSS measures severity, not risk, and should not be altered to reflect business risk. Record business likelihood and impact separately. See CVSS is not business risk for more.
Turn cases into work
After the workshop, add the cases to the backlog as security requirements or acceptance criteria. Reference the ID in the design doc and in the test name. Automated tests then catch a countermeasure that someone accidentally removes later.
Finally, give the list of addressed cases to whoever does penetration testing and ask them to confirm each attack no longer works.
Examples to copy
Technical: "As an attacker, I upload a file with a double extension so the server treats it as executable." Business: "As an attacker, I change the quantity to a negative number so the order total becomes a refund." Notice that each names one feature, one action and one harm. If a case cannot be tested, rewrite it until it can.
Quick check
Is an abuse case the same as a threat?
They overlap. An abuse case is a threat written in a form developers and product owners can act on, as a story tied to one feature.
Sources
Last reviewed: 19 October 2026.
