In STRIDE, what does the Elevation of Privilege category cover and which property does it violate?
answer
- the last letter of STRIDE
- a property under attack, not an exploit
- not identity - permission
- processes, not flows or stores
- least privilege limits, does not prevent
basics
~20 sElevation of Privilege is STRIDE's category for an actor gaining rights it was never granted - doing something it is not permitted to do. It violates authorization, and the answering controls are authorization decisions plus least privilege.
solid answer
~50 sElevation of Privilege is the E in STRIDE, and the property it attacks is authorization: whether an actor is allowed to perform the action, as distinct from whether it is who it claims to be. It covers vertical cases - a low-privilege user reaching administrative function - and horizontal ones, where an actor reaches another tenant's or another user's rights. On a data-flow diagram it attaches to processes, the elements that run code and make decisions, which is why the classic STRIDE-per-element chart checks E against processes rather than flows or stores. Two design shapes produce most of it: a component that acts on a less-privileged caller's input while holding authority that caller lacks, and a component that simply holds far more privilege than its job needs. The answering families are an authorization decision on every privileged action, least privilege, and isolation between principals.
go deeper
Be ready to say which letter of STRIDE this is, which property it attacks - authorization, not authentication - and give one plain example such as a normal user reaching an admin-only action.
Explain why it attaches to processes on a data-flow diagram, why vertical and horizontal cases both count, and why an over-privileged account is a condition that amplifies the threat rather than the threat itself.
Show that you look for elevation where privilege changes: at boundary crossings and at calls between components running under different identities. Expect to name the control layers and say what least privilege does and does not buy.
Own the framing argument: a model where every threat is graded E has stopped producing distinct mitigations. Be ready to explain how you keep category discipline across many teams without turning it into bureaucracy.
## What the category names STRIDE names six threat categories, each defined by the security property it attacks: Spoofing attacks authentication, Tampering attacks integrity, Repudiation attacks non-repudiation, Information Disclosure attacks confidentiality, Denial of Service attacks availability, and **Elevation of Privilege attacks authorization**. That framing matters more than the word "privilege". Elevation of Privilege is not "becoming root"; it is any case where an actor performs an action it was not permitted to perform, or acquires rights it was never granted. It helps to keep four words straight while modeling. A **threat** is what could go wrong ("an analyst could run a query outside their remit"). A **vulnerability** is the flaw that would let it happen ("the tool passes the query straight through under one shared account"). A **risk** is the rated consequence of that threat given that flaw. A **control** is what you do about it. "The service runs as an administrator" is not itself the threat - it is a condition that makes an elevation threat both likely and severe. ## The two shapes it takes **Vertical elevation** moves an actor up a privilege ladder: a normal user performing an administrative action, an application process gaining the rights of the account it runs under, a tenant reaching an operator-only function. **Horizontal elevation** moves an actor sideways into rights it was never issued: reading or changing another user's records, acting inside another tenant's data, invoking an endpoint scoped to a different role. Both are Elevation of Privilege in STRIDE, because both are failures of "may this actor do this?". ## Where it lives on the diagram In STRIDE-per-element - the practice of walking a data-flow diagram and asking which categories apply to each element - Elevation of Privilege is checked against **processes**. External entities get Spoofing and Repudiation; data flows and data stores get Tampering, Information Disclosure and Denial of Service; only processes, the elements that execute code and make decisions, can be induced to act with rights they should not use. A flow can be read or altered, but a flow does not decide anything, so it cannot be tricked into deciding wrongly. That is also why elevation threats cluster wherever privilege *changes*: at a trust boundary crossing, where a request arrives from a less-trusted source; at a call from one component to another that runs under a different account; at any point where input from one principal reaches code executing as another. Those junctions are the first places to look, and a design with many such junctions and few decision points will hide elevation threats. ## The two recurring design patterns The first is the **confused deputy**: a component holds authority - a credential, a privileged network position, a broad token - and acts on requests from callers who do not hold that authority, without checking on whose behalf it is acting. The caller does not need to break anything; it simply asks the deputy to use its own authority. The second is the **over-privileged component**: a component holds far more rights than its function needs, so any flaw anywhere in it becomes the full extent of that privilege. An internal "run a report" tool that executes every analyst's query under one database superuser is the canonical case - the tool works perfectly, but any injection, bug or misuse in it now acts with rights no analyst was ever granted. ## How you answer it The mitigation family is authorization, in three layers. First, make an explicit authorization decision for every privileged action, based on the identity of the actor that actually requested it rather than the identity of the component performing it. Second, apply least privilege so the rights any component can lend out are small - this **limits the reach** of an elevation, it does not prevent it. Third, isolate principals so that separate duties run under separate identities, and privileges that must exist are held for the shortest possible time. ## Common mistakes The most common analysis failure is grading everything as Elevation of Privilege, because most attack chains eventually end in unauthorized action. STRIDE's value comes from naming the property under attack at *this* element, so a stolen credential at a login is Spoofing, an altered record in transit is Tampering, and an actor performing an operation its role does not permit is Elevation. The second common mistake is answering an elevation threat with authentication - knowing exactly who the caller is does nothing if the code never asks whether that caller may do the thing.
- A candidate labels almost every threat in the model Elevation of Privilege. What has gone wrong?They are labelling the end of the attack chain rather than the property under attack at the element in front of them. Most chains finish in unauthorized action, so if that is the test, every letter collapses into E and the analysis stops generating distinct mitigations. The discipline is to ask, at this element, which property fails first: a forged identity is Spoofing, an altered message is Tampering, an action the actor may not perform is Elevation.
- Is "the service runs under an administrator account" a threat, a vulnerability, or something else?It is a condition of the design - closest to a vulnerability - not a threat. The threat is the sentence about what could go wrong: an attacker who gets code execution in this process acts with administrator rights over everything that account can reach. Writing the condition alone gives you nothing to rate and nothing to mitigate; writing the threat gives you both, and makes the over-privileged account the obvious control point.
- Does horizontal access to another user's records count as Elevation of Privilege in STRIDE?Yes. STRIDE's E is defined by the property violated - authorization - not by moving up an administrative ladder. An actor reading or modifying another user's or another tenant's records is performing an action it was not permitted to perform, so it belongs under Elevation of Privilege even though its nominal role never changes. Categorising it as Information Disclosure describes the consequence but hides the missing authorization decision that caused it.
saying these in an interview costs you the question
- Says Elevation of Privilege only means becoming root or administrator
- Labels every threat in the model as Elevation of Privilege
- Names an exploit technique instead of the property under attack
- Answers an elevation threat with stronger authentication
- Claims least privilege prevents elevation rather than limiting its reach
- Treats cross-tenant access as disclosure only, never as elevation