# STRIDE

> Six questions — spoofing, tampering, repudiation, disclosure, denial of service, elevation — to ask of every part of a design.

Concept · Application & cloud security · https://levelcode.org/concepts/stride

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 |
|---|---|---|---|
| **S**poofing | Authentication | Calling the internal API pretending to be the billing service | mTLS, signed tokens, MFA |
| **T**ampering | Integrity | Changing the price field in a request; editing a file in a build | Server-side validation, signatures, checksums |
| **R**epudiation | Non-repudiation | "I never approved that refund" — and no log proves otherwise | Audit logs that can't be edited, with user identity |
| **I**nformation disclosure | Confidentiality | An error page leaking a stack trace; a public S3 bucket | Encryption, access control, safe error handling |
| **D**enial of service | Availability | One client sending huge uploads or expensive queries | Rate limits, quotas, timeouts, size limits |
| **E**levation of privilege | Authorization | A normal user reaching an admin endpoint by changing an ID | Authorization checks on every request, [least privilege](https://levelcode.org/concepts/least-privilege) |

## Running it

1. **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).
2. **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.
3. **Write each threat down** concretely: "An attacker who steals a session cookie can…"
4. **Rate and decide:** mitigate, accept, transfer or avoid. Track the mitigations as ordinary tickets.
5. **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](https://levelcode.org/concepts/sql-injection), [XSS](https://levelcode.org/concepts/xss-and-csp), and now [prompt injection](https://levelcode.org/concepts/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](https://levelcode.org/roadmaps/devsecops/threat-modeling) works through a full example.