Concept · Application & cloud security
STRIDE
Six questions — spoofing, tampering, repudiation, disclosure, denial of service, elevation — to ask of every part of a design.
3 minthreat modelingspoofingtamperingelevation of privilege
Threat modeling asks "what could go wrong?" before attackers do. STRIDE is a checklist that keeps the answer from being "whatever I happened to think of." For each element of your design (a process, a data store, a data flow, a trust boundary), go through six categories of threat:
| Threat | Violates | Example | Typical control |
|---|---|---|---|
| Spoofing | Authentication | Calling the internal API pretending to be the billing service | mTLS, signed tokens, MFA |
| Tampering | Integrity | Changing the price field in a request; editing a file in a build | Server-side validation, signatures, checksums |
| Repudiation | Non-repudiation | "I never approved that refund" — and no log proves otherwise | Audit logs that can't be edited, with user identity |
| Information disclosure | Confidentiality | An error page leaking a stack trace; a public S3 bucket | Encryption, access control, safe error handling |
| Denial of service | Availability | One client sending huge uploads or expensive queries | Rate limits, quotas, timeouts, size limits |
| Elevation of privilege | Authorization | A normal user reaching an admin endpoint by changing an ID | Authorization checks on every request, least privilege |
Running it
- Draw the data-flow diagram: actors, processes, stores and flows. Mark trust boundaries, the lines where data crosses from less trusted to more trusted (internet → API, API → database, CI → production).
- Walk each element crossing a boundary through the six letters. Different element types are prone to different threats. Data flows mostly face T, I and D; processes can face all six.
- Write each threat down concretely: "An attacker who steals a session cookie can…"
- Rate and decide: mitigate, accept, transfer or avoid. Track the mitigations as ordinary tickets.
- Revisit when the design changes, not once a year.
Keeping it useful
- Do it during design reviews, when changes are cheap. A 45-minute session with the people building the feature beats a long document nobody reads.
- Focus on boundaries. Most real vulnerabilities sit where untrusted input arrives: injection, XSS, and now prompt injection for AI features.
- Write things down even when you accept the risk. "Accepted: internal tool, VPN only" is a decision someone can revisit later; silence isn't.
The threat modeling lesson works through a full example.