Most abuse case workshops stall at a blank sheet: the team knows features can be misused, but nobody arrives with a ready list of the ways identity, payment and API features are actually abused. This template is a reusable abuse case library for [Organisation]: a set of pre-written scenarios, each tied to an attack reference, a business risk rating and a testable countermeasure, that product teams copy into their own workshop and adapt. It covers sign-up, login, recovery, sessions, machine credentials, checkout, refunds, promotions and APIs. It is for application security teams, product owners, fraud teams and testers. The workshop method and the step from abuse case to security requirement are explained in the Security Requirements and Abuse Cases Guide; this page is the library itself.
How to use this template
- Copy sections 3 to 8 into the workbook or tracker your teams use. Keep the IDs so that requirements, tests and risk acceptances can point back to the library entry.
- The record fields in section 3 follow the ABUSE CASES sheet described in the OWASP Abuse Case Cheat Sheet (feature, attack description, attack reference, business risk, CVSS where relevant, kind, countermeasure and handling decision). OWASP has archived that cheat sheet as historical, but the record structure still works.
- Do not run every entry against every feature. Pick the families that match the features in scope, then delete, merge or rewrite entries until each one describes your system.
- Replace text in square brackets, such as [Organisation], [N] and [risk owner], with your own values. Bracketed thresholds are NHI Mgmt Group suggestions, not values from a standard.
- Attack references use OWASP API Security Top 10 2023 (API1 to API10), OWASP Automated Threats to Web Applications (OAT IDs) and MITRE CAPEC 2.1 IDs. Check each reference still matches the behaviour you describe.
1. Purpose
This library gives [Organisation] a shared starting set of misuse scenarios for features that handle identity, money and data through APIs. It exists so that abuse cases are considered at design time, turned into testable requirements and acceptance criteria, and tracked to a decision (address or accept). It supports NIST SP 800-53 SA-8 (Security and Privacy Engineering Principles), SA-11 (Developer Testing and Evaluation) and RA-3 (Risk Assessment), and the NIST CSF 2.0 outcome PR.PS-06, that secure software development practices are integrated into the lifecycle.
2. Scope and ownership
- The library applies to any new or changed feature that creates accounts, authenticates people or machines, grants access, moves money or value, or exposes data or functions through an API.
- [Application security team] owns the library and reviews it [every six months] and after any incident or penetration test finding that reveals a scenario it does not contain.
- Each product team owns the copies it adapts, the business risk ratings it assigns and the handling decisions it records.
- Fraud, customer support and identity teams contribute scenarios from their own case data. Scenarios that come from real incidents are marked with source "Internal incident" and a reference number.
3. Abuse case record format
| Field | What to record |
|---|---|
| ID | Library ID (for example ID-03) or local ID (ABUSE_CASE_001) |
| Feature ID and name | The feature the case applies to, from the FEATURES list |
| Actor | Anonymous user, registered customer, insider, partner, bot operator, compromised machine identity |
| Abuse description | One or two sentences in business language: what the actor does and what they gain |
| Attack reference | OWASP API Top 10, OAT or CAPEC ID |
| Kind | Technical (exploits a flaw) or Business (uses a feature as built, for an unintended gain) |
| Business risk rating | [Low / Medium / High / Critical] from the [Organisation] risk matrix, kept separate from any CVSS score |
| Countermeasure | The requirement or control, written so a tester can verify it |
| Test | How it will be checked: unit test, integration test, DAST rule, penetration test case, fraud rule |
| Detection signal | What log event or metric would show this abuse happening in production |
| Handling decision | To address (with ticket) or Risk accepted (with approver, reason and expiry) |
The detection signal field is an NHI Mgmt Group addition to the OWASP structure. Business abuse often passes every functional test, so the only practical control may be noticing it in production.
4. Identity and account scenarios
| ID | Abuse case | Reference | Countermeasure (testable) | Detection signal |
|---|---|---|---|---|
| ID-01 | Bot operator replays leaked username and password pairs against login | OAT-008, CAPEC-600 | Breached password check at sign-up and reset; phishing-resistant MFA option; per-IP and per-account throttling | Login failure ratio by source; many accounts per device |
| ID-02 | Attacker guesses passwords for one targeted account | OAT-007, CAPEC-49 | Progressive delay per account; lockout that cannot be used to deny service to the owner | Failures per account per hour above [N] |
| ID-03 | Mass creation of fake accounts to claim sign-up credit or seed spam | OAT-019 | Value granted only after verified activity; per-device and per-payment-instrument sign-up limits | Sign-ups per device, domain or IP range |
| ID-04 | Attacker uses password reset to take over an account (guessable answers, reset link to a changed email) | CAPEC-50 | Single-use, short-lived reset tokens; notify old and new contact details; no reset after recent contact change without step-up | Reset followed by contact change within [24 hours] |
| ID-05 | Caller persuades support to change the phone number or reset MFA | CAPEC-407 | Help desk verification policy with callback; MFA reset holds for [N hours] with owner notification | MFA resets per agent; resets followed by high-value actions |
| ID-06 | Stolen session cookie or token reused from another device | CAPEC-60 | Session binding or re-validation on device or network change; short idle timeout for sensitive roles | Same session from two distant locations |
| ID-07 | User floods another person with MFA push prompts until one is approved | CAPEC-416 | Number matching or phishing-resistant factors; cap on prompts per [10 minutes] | Denied prompts followed by an approval |
| ID-08 | Forgotten test or vendor account with a local password reaches production | CAPEC-555 | All interactive access through SSO with MFA; every account has a named owner and expiry | Logins from accounts with no owner or past expiry |
See the Account Takeover Prevention Guide, the Account Recovery and Help Desk Security Guide and the MFA Fatigue and Bypass Guide.
5. Machine identity and integration scenarios
These scenarios are often missing from workshops because no human user story covers them. Add them whenever the feature issues, accepts or stores API keys, OAuth tokens, webhook secrets or service account credentials.
| ID | Abuse case | Reference | Countermeasure (testable) | Detection signal |
|---|---|---|---|---|
| NHI-01 | Customer API key committed to a public repository is used by a third party | CAPEC-21 | Keys carry a recognisable prefix for secret scanning; scoped and expiring keys; one-click revoke and rotate | Key used from new ASN or country; usage after owner reports leak |
| NHI-02 | Integration token with broad scope is used for actions far outside the integration's purpose | CAPEC-122 | Scopes per integration, least privilege by default; admin consent for high-risk scopes | Token calling endpoints it has never called before |
| NHI-03 | Forged webhook calls trigger order or account changes | CAPEC-633 | Signed webhooks with timestamp and replay window; reject unsigned payloads | Signature failures per sender |
| NHI-04 | Departed employee's personal token keeps a production integration alive | CAPEC-555 | Integrations run as owned service identities, not personal tokens; offboarding revokes personal tokens | Token activity after owner's account is disabled |
| NHI-05 | AI assistant with tool access is instructed by hidden text to perform an account action | OWASP LLM01:2025 | Server-side authorisation on every tool call; human confirmation for value-moving actions | Tool calls that follow external content ingestion |
See the API Key Management Guide, the Webhook Secrets Security Guide and the Service Account Security Guide.
6. Payment and value scenarios
| ID | Abuse case | Reference | Countermeasure (testable) | Detection signal |
|---|---|---|---|---|
| PAY-01 | Stolen card numbers tested with small payments | OAT-001 | Velocity limits per account, device and card BIN; 3-D Secure on risk signals; anti-automation on payment form | Authorisation decline rate; many cards per device |
| PAY-02 | Gift card or voucher codes enumerated until valid ones are found | OAT-002 | Long random codes; attempts limited per account and IP; lockout on repeated failures | Failed redemptions per source |
| PAY-03 | Price, quantity or currency changed in the client request | CAPEC-162, CAPEC-39 | Server recalculates price from catalogue; reject negative or fractional quantities | Order totals that differ from server-side recalculation |
| PAY-04 | Same discount or refund claimed twice by sending parallel requests | CAPEC-26 | Idempotency keys; atomic state change on redemption | Duplicate redemptions within [1 second] |
| PAY-05 | Bot buys limited stock for resale | OAT-005, API6:2023 | Per-customer purchase cap; queueing or anti-automation on launches | Purchases per account and address cluster |
| PAY-06 | Refund issued to a different payment method than the original purchase | Business (no single ID) | Refunds only to the original instrument; manager approval above [amount] | Refunds to new instruments; refunds per agent |
| PAY-07 | Loyalty points moved out of compromised accounts | OAT-012 | Step-up authentication for transfers and redemptions; hold on new payees | Point transfers soon after login from a new device |
See the Card Testing and Carding Attacks Defence Guide, the Promotion and Bonus Abuse Guide and the Refund and Returns Fraud Guide.
7. API and data scenarios
| ID | Abuse case | Reference | Countermeasure (testable) | Detection signal |
|---|---|---|---|---|
| API-01 | Authenticated user changes an object ID to read another customer's record | API1:2023 | Object-level authorisation check on every request; non-sequential identifiers | One caller reading many owners' objects |
| API-02 | User sets a field such as role or account balance in an update request | API3:2023 | Allow-list of writable properties per role; response schemas that omit internal fields | Rejected property writes per caller |
| API-03 | Ordinary user calls an administrative endpoint directly | API5:2023, CAPEC-58 | Function-level authorisation enforced server-side, deny by default | 403 responses on admin routes per caller |
| API-04 | Scraper harvests the full product or profile catalogue | OAT-011 | Page size caps; per-key quotas; authenticated access for full records | Sequential pagination at machine speed |
| API-05 | Script triggers thousands of SMS or emails through a send feature | API4:2023, OAT-017 | Per-account and per-destination send limits; provider spending cap | Messaging cost per hour |
| API-06 | Old API version without current checks remains reachable | API9:2023 | API inventory with retirement dates; gateway blocks retired versions | Traffic to versions marked retired |
| API-07 | Feature fetches a URL supplied by the user and reaches internal services | API7:2023 | Allow-list of destinations; block internal ranges and cloud metadata addresses | Outbound requests to internal ranges |
See the API Security Guide, the Rate Limiting and API Abuse Guide and the Business Logic Vulnerabilities Guide.
8. Handling decisions and sign-off
- Every abuse case selected for a feature reaches one of two decisions before release: To address (linked ticket, requirement or acceptance criterion) or Risk accepted.
- Risk accepted needs a written reason, the [risk owner]'s approval and an expiry date of no more than [12 months]. Cases rated Critical cannot be accepted by the product team alone. See the Security Exceptions and Risk Acceptance Guide.
- Business risk is rated with the [Organisation] risk matrix. CVSS describes technical severity, not business risk, and is recorded separately where it applies.
- Countermeasures marked as addressed are verified by the test named in the record before release, and the evidence is linked.
Implementation guidance
Rolling it out
- Start with one product team and one feature set that moves value, such as checkout or account recovery. Run a workshop using the method in the Security Requirements and Abuse Cases Guide, with this library open as the prompt list.
- Invite fraud and customer support analysts as well as testers. Many Business scenarios (PAY-06, ID-05) are known to them long before security sees them.
- Turn each To address case into an acceptance criterion on the user story or a requirement in the backlog, and into a test. The OWASP Web Security Testing Guide business logic section (4.10) has test ideas for workflow circumvention, function use limits and process timing (tests 4.10.4 to 4.10.6).
- Feed the detection signals to the team that owns production monitoring, so each accepted or partially addressed case has a way to be seen.
- After [one quarter], add scenarios found in incidents, penetration tests and fraud cases, and remove entries no team has used.
Choosing what to include
| Feature in scope | Start with |
|---|---|
| Sign-up, login, recovery | Section 4 |
| Public API, partner API, webhooks | Sections 5 and 7 |
| Checkout, refunds, promotions, loyalty | Section 6, plus ID-01 and ID-06 |
| AI assistant or agent with tools | NHI-02, NHI-05, API-01, API-03 |
| Internal admin tooling | ID-08, API-03, NHI-04 |
Measuring it
- Coverage: share of releases touching identity, payment or API features with a recorded abuse case review.
- Closure: share of To address cases with a passing test linked at release.
- Escapes: production incidents or penetration test findings that match a library entry marked addressed (a sign the countermeasure or test is weak).
- Library growth: new entries added from internal incidents per quarter.
- Expired acceptances: Risk accepted cases past their expiry without review.
Framework mapping
| Template part | Mapping |
|---|---|
| Scenarios and attack references | NIST SP 800-53 RA-3; CAPEC 2.1; OWASP API Security Top 10 2023; OWASP OAT |
| Countermeasures as requirements | NIST SP 800-53 SA-8; OWASP ASVS 5.0 |
| Tests | NIST SP 800-53 SA-11; OWASP WSTG 4.10 |
| Lifecycle integration | NIST CSF 2.0 PR.PS-06 |
Standards and references
- OWASP: Abuse Case Cheat Sheet (Historical)
- OWASP: API Security Top 10 2023
- OWASP: Automated Threats to Web Applications
- MITRE: Common Attack Pattern Enumeration and Classification (CAPEC)
- OWASP: Web Security Testing Guide
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
Related NHI Mgmt Group resources: Threat Model Template, Application Security Requirements from ASVS, Secure Software Development Lifecycle (SSDLC) Guide, Bot Management Guide.