STRIDE Threat Modeling with AI: A Step-by-Step Guide
How to run a STRIDE threat model with Claude — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege — with a full worked example against a login endpoint.
STRIDE is a structured threat-modeling framework — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege — and it maps unusually well onto how an LLM reasons, because each category is a targeted question you can ask about a specific component rather than an open-ended "is this secure?" prompt.
Why STRIDE prompts beat generic security review prompts
"Review this code for security issues" produces a shallow, generic list. Walking the model through each STRIDE category against a specific data-flow diagram or endpoint forces it to reason about concrete attack vectors: can this endpoint be spoofed, can this payload be tampered with in transit, can this action be repudiated, and so on.
A STRIDE prompt structure
- Describe the component and its trust boundaries (what's external input, what's internal, what crosses a network hop).
- For each STRIDE category, ask the model to identify concrete threats specific to this component — not generic security advice.
- For each identified threat, require a proposed mitigation and its trade-off.
- Rank findings by exploitability and blast radius, not just by category.
Worked example: a login endpoint
Context: POST /api/auth/login accepts { email, password }, checks against a Postgres users table (password hashed with bcrypt), issues a JWT on success, and returns a generic "invalid credentials" message on failure. Rate limiting is currently IP-based, 10 requests/minute. Trust boundary: this endpoint is internet-facing; the database is internal-only.
Task: Run a STRIDE analysis on this endpoint.
Output format: One table row per identified threat — Category | Threat | Exploitability | Mitigation.| Category | Threat | Mitigation |
|---|---|---|
| Spoofing | Credential stuffing using leaked password lists — attacker isn't the real user but has valid-looking credentials | Layer in device/behavioral signals; don't rely on password correctness alone for high-value accounts |
| Tampering | None directly on this request (HTTPS assumed) — but JWT payload could be tampered with if signature isn't verified downstream | Confirm every consumer of the JWT verifies the signature, not just decodes the payload |
| Repudiation | No login attempt (success or failure) is logged with enough detail to investigate later | Log timestamp, IP, and outcome for every attempt, success or failure |
| Information disclosure | Timing difference between 'user not found' and 'wrong password' paths could leak which emails are registered | Ensure both paths take equivalent time (constant-time comparison, or hash-and-compare even for unknown emails) |
| Denial of service | IP-based rate limit is trivially bypassed with a botnet — 10 req/min per IP across thousands of IPs is still a large attack | Add a secondary limit keyed on the target email/account, independent of source IP |
| Elevation of privilege | If the JWT's role claim is set from client-supplied data anywhere in the pipeline, an attacker could self-elevate | Verify role claims are set only server-side from the database record, never echoed from request input |
Elevation-of-privilege findings are usually the highest-severity output of a STRIDE pass. Auth code benefits from a dedicated, focused review prompt rather than being one line item in a broader sweep — see the Auth Deep Review prompt pattern.
Prioritizing what you find
Not every STRIDE finding needs to be fixed before shipping. Ask the model to score each finding on exploitability (how easy is this to actually pull off?) and blast radius (what's the worst case if it's exploited?) — a low-exploitability, low-blast-radius finding can go in the backlog, while a high/high finding blocks release.
For each threat identified above, score Exploitability and Blast Radius as Low/Medium/High, and recommend which findings must be fixed before this endpoint ships versus which can be tracked as follow-up work.The Existing Project Analysis & Modernization program includes a dedicated Security Analysis module covering STRIDE modeling and authentication/authorization deep review as part of production-grade quality gates.