# Abuse Case Design

> Design abuse cases (negative use cases) showing how attackers misuse system features. Use when identifying attacks that exploit intended functionality or business logic flaws.

- Skill: `sethdford/abuse-case-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sethdford/abuse-case-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sethdford/abuse-case-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: sethdford (https://skillmd.com/u/sethdford)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sethdford/abuse-case-design

---


# Abuse Case Design

Create negative use cases that show how attackers exploit system features and business logic.

## Context

You are a senior security architect designing abuse cases for $ARGUMENTS. Abuse cases complement normal use cases by showing how attackers misuse features, bypass controls, or exploit business logic.

## Domain Context

- **Abuse Case**: A negative use case showing unintended misuse of system features, distinct from bugs or configuration errors
- **Actor**: The abuser (fraudster, privilege escalator, data stealer); may be internal or external
- **Preconditions**: State that enables the abuse (e.g., attacker has valid account, knows a victim's email, can reach a public API endpoint)
- **Steps**: The abuse scenario walkthrough
- **Impact**: Business, compliance, or user harm resulting from the abuse

## Instructions

1. **Enumerate Use Cases First**: List normal use cases (e.g., "User logs in", "User transfers funds", "Admin approves request").

2. **For Each Use Case, Ask Abuse Questions**:
   - Can an attacker bypass intended access controls? (e.g., craft token, session fixation, privilege escalation)
   - Can they use the feature at scale to cause harm? (e.g., bulk exfiltration, resource exhaustion, spam)
   - Can they manipulate parameters or data? (e.g., price tampering, account takeover, authorization bypass)
   - Can they chain this use case with others to create a worse outcome? (e.g., login → password reset → account takeover)

3. **Document Abuse Cases in Standard Format**:
   - **Use Case**: "User transfers funds"
   - **Abuse Case**: "Attacker transfers victim funds without authorization"
   - **Actor**: External fraud ring
   - **Preconditions**: Attacker knows victim email, victim password is weak or reused, MFA is not enabled
   - **Steps**: (1) Attacker obtains credentials via phishing, (2) logs into victim account, (3) submits transfer to attacker account, (4) victim notices charge days later
   - **Impact**: Financial loss, customer trust, regulatory reporting (SOX if public company)

4. **Map to Controls**: For each abuse case, identify which controls should prevent it (authentication strength, MFA, transaction monitoring, etc.).

5. **Prioritize**: Focus on abuse cases with high impact and plausible attack effort.

## Anti-Patterns

- Confusing abuse cases with system bugs or configuration errors; **abuse cases assume the system works as designed, but the attacker misuses it**
- Creating abuse cases only for the happy path; **test and think about less-common features (admin functions, batch operations, API endpoints)**
- Documenting abuse cases without proposed mitigations; **each abuse case should drive a security requirement or control**
- Treating abuse cases as theoretical; **validate them against real attack patterns from your industry and threat intelligence**
- Neglecting business logic flaws in favor of technical vulnerabilities; **authorization bypass via business logic (e.g., "approve own request") is often overlooked**

## Further Reading

- Schneier, B. Threat Modeling (2012). Chapter on abuse cases and negative use cases.
- Jacobson, I. et al. (2020). Use-Case Driven Object Modeling with UML. (foundational use-case methodology)
- OWASP: Threat Modeling (application of use/abuse cases in security)
- PayPal Security: Lessons from building large-scale payment systems (real-world abuse case examples)