STRIDE: a vocabulary for what can go wrong

Where STRIDE comes from, and what it actually is

STRIDE is a mnemonic invented at Microsoft in 1999 to give engineers a structured way to ask “how could this break?” Before it, threat brainstorming was whatever the most paranoid person in the room happened to remember. STRIDE’s insight is small but powerful: every security goal has an inverse, and that inverse is a threat. So instead of listing attacks (there are infinitely many), you list the six ways a security property can be violated. Six prompts cover the space.

The trick to internalizing STRIDE is to read it as a list of negations. Authentication says “you are who you claim to be” — negate it and you get Spoofing. Integrity says “data and code aren’t altered” — negate it and you get Tampering. Each letter is a property turned inside out:

• Spoofing negates authentication — pretending to be someone or something you are not.
• Tampering negates integrity — modifying data or code you should not be able to change.
• Repudiation negates non-repudiation — performing an action and then plausibly denying it, because nothing recorded it.
• Information disclosure negates confidentiality — exposing data to someone not authorized to see it.
• Denial of service negates availability — making a system unusable for legitimate users.
• Elevation of privilege negates authorization — gaining capabilities beyond what you were granted.

That one-to-one mapping is the whole engine. If you can recite the six properties, you can regenerate STRIDE from scratch — and, more importantly, when you find a threat you can name which guarantee it breaks, which tells you which class of control fixes it.

The six, with concrete shape and a mitigation each

A vocabulary is useless until each word has a picture attached. Here is each STRIDE letter grounded in a property, a concrete example from an ordinary web app, and the control family that answers it.

Notice the mitigation column is families, not single fixes. “Strong auth” is a direction, not a line of code. STRIDE’s job is to point you at the right family; choosing the specific control is the next, separate step. The value is that you never again ask “is it secure?” — you ask six questions whose answers you can actually defend in a review.

STRIDE-per-element: where to point the six questions

The six categories are only half the method. The other half is where you ask them. STRIDE-per-element means you don’t interrogate the whole system at once — you walk it one piece at a time and apply the relevant subset of STRIDE to each piece.

The reason this matters: not every threat applies to every element. The categories cluster by element type. External entities (users, third-party services) can be Spoofed and can Repudiate, but you don’t “tamper with” a user. Processes (your services) are exposed to all six. Data stores (databases, caches, files) feel Tampering, Information disclosure, Denial of service, and Repudiation (if logs live there) — but a database doesn’t get “spoofed” the way a user does. Data flows (requests crossing a boundary) are where Tampering, Information disclosure, and Denial of service concentrate. Mapping element type → applicable letters keeps the exercise finite and stops you from generating nonsense threats.

A worked pass: the “export my data” endpoint

Take the feature from the hook — GET /export returns the signed-in user’s data as a download. Walk the three elements and ask STRIDE.

The user (external entity). Spoofing: can someone present another user’s session and export their data? The control family is strong authentication — short-lived, signed session tokens, not a guessable id. Repudiation: if a user later claims “I never exported anything,” can you prove otherwise? You need an audit log entry tied to their identity and a timestamp.

The request flow (GET /export crossing the network boundary). Tampering: can a client change a query parameter — say ?user_id= — to redirect the export at someone else? Information disclosure: is the response over TLS, or could it be read on the wire? The fix families are server-side parameter binding (derive the user from the session, never from the request) and transport encryption.

The API process and the database (process + store). Elevation of privilege: does the handler fetch by WHERE id = ? alone, letting any authenticated caller export any row — or does it scope to the owner? Denial of service: can someone request an export so large it pins a CPU or fills a disk, with no size cap or rate limit? Information disclosure: does the export accidentally include columns the user shouldn’t see — internal flags, other people’s references?

That single endpoint, walked through STRIDE-per-element, produced eight concrete, fixable questions in about a minute. None required a tool. That is the entire pitch: structure beats memory.

The senior nuance: a prompt, not a checklist

The most common way teams misuse STRIDE is treating the six letters as a checklist to tick: “Spoofing — done, we have login. Next.” That collapses a thinking tool into a compliance ritual and is how real threats slip through. STRIDE is a prompt for completeness — its job is to make sure you considered each category, not to certify that one sentence per letter makes you safe.

Two failure modes sit on either side of that line. Over-applying: mechanically generating a threat for every letter on every element produces a swamp of low-value entries — “the load balancer could be spoofed” — that buries the three threats that actually matter and exhausts the team’s appetite for the exercise. Under-applying: stopping at the first plausible threat per element, so the second, nastier one never surfaces. The senior move is judgment on top of structure: use all six letters to generate candidates, then triage ruthlessly by likelihood and impact, and write down only the threats worth a mitigation decision. STRIDE gives you the questions; you still have to think about the answers. A threat model with forty rote entries and no priorities is worse than one with five real ones and a plan.