STRIDE turns "what can go wrong?" into a checklist. Walk each element of your diagram against six threat categories — Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege.
STRIDE is a mnemonic that makes threat discovery systematic instead of relying on inspiration. Each letter is the violation of a security property. You apply it element by element (STRIDE-per-element) or flow by flow — asking, for each, "how could this category happen here?" It is deliberately exhaustive so junior and senior engineers find the same threats.
Threat Violates Ask...
S Spoofing Authentication can someone pretend to be
another user / service?
T Tampering Integrity can data be modified in
transit or at rest?
R Repudiation Non-repudiation can someone deny doing it
because we have no log?
I Information disclosure Confidentiality can data leak to someone
who shouldn't see it?
D Denial of service Availability can it be made unavailable
or too slow?
E Elevation of privilege Authorization can a user gain rights they
shouldn't have?Not every category applies to every element, which keeps the walk fast. External entities can be spoofed and can repudiate; data stores suffer tampering, disclosure, DoS, and repudiation (missing logs); processes are vulnerable to all six. Use this map to skip the combinations that do not exist and focus effort.
Element S T R I D E
External entity x x
Process x x x x x x
Data store x (x) x x
Data flow x x x
x = strongly applies, (x) = applies (e.g. a store that should
be an audit log can enable repudiation if it can be edited).
So: spend the most time on processes and on flows that cross
trust boundaries — that is where the whole alphabet applies.Apply STRIDE to the file-upload DFD from the previous lesson. Notice how the checklist forces you past the obvious "malware upload" into authz, DoS, and privilege issues you would otherwise miss. Each finding becomes a row you will rate and mitigate next.
Upload API + its flows:
S attacker calls upload with a stolen/guessed session -> authn on every request
T filename/path from user used as S3 key -> path traversal, overwrite others' files
R no audit log of who uploaded what -> can't investigate abuse later
I bucket is public + predictable URLs -> enumerate & read others' private photos
D 100MB uploads with no limit -> fill storage, exhaust the worker
E "image" is actually a polyglot/SVG with script -> stored XSS, or SSRF via
the worker fetching a remote URL in the file
Six prompts, six real threats — none of which was "add antivirus".Capture each threat in a lightweight, consistent format so it can be rated and tracked. A one-line-per-threat table in the repo beats a perfect tool nobody updates. Include the element, the STRIDE letter, the concrete scenario, and a placeholder for the mitigation you will decide in a later lesson.
# threat-model/upload.yaml
threats:
- id: UP-01
element: Upload API flow (user -> API)
stride: Tampering
scenario: filename used directly as storage key -> overwrite other users' objects
mitigation: server-generated opaque key; never trust client path
status: open
- id: UP-02
element: Object storage
stride: Information disclosure
scenario: public bucket + guessable URLs -> read others' private images
mitigation: private bucket, signed URLs, per-object authz
status: open