Short answer: Draw the attacker's path from starting access to the harmful action. At each step, record what the attacker must possess or cause, what control should intervene, and whether that fact is observed, inferred, or unknown. Rank practical difficulty from the complete path, not from the most dramatic endpoint or the number of steps alone. If a decisive prerequisite is unknown, give a conditional assessment and assign the fact-finding work; do not turn missing evidence into “hard to exploit.” The answer changes when an alternate route, leaked identifier, role policy, or deployment setting changes.
This guide is for a security engineer reviewing a supported claim before handing it to a developer. It describes source and configuration review. Any live validation must be authorized and safely scoped. The example is invented and no exploit was run.
Work backward from a concrete harm
Start with a one-sentence consequence, such as “a user from one project could download another project's export.” Then ask what an attacker must do immediately before that consequence. Repeat until you reach the actor's starting position. The backward walk exposes hidden assumptions: a file identifier must be known, an API must be reachable, a session must have some role, an export must exist, and a storage layer must return its bytes.
The terms matter. An access requirement describes a credential, role, network position, or membership the attacker must already have. A prerequisite is another necessary condition, such as a feature being enabled or a target object existing. A control is something that can block the path, such as an object ownership check. Effort describes the work needed once those conditions are met; repeatability asks whether the same approach would work across targets. Keep these separate. FIRST's CVSS v4.0 metrics include attack vector, attack requirements, privileges, and user interaction, but a local path review still needs the actual service and control evidence.
Worked case: a project export download
Illustrative system and numbers. A B2B platform has projects inside customer accounts. The route /projects/{project_id}/exports/{export_id} returns a generated report. A source review finds that middleware checks the caller's membership in project_id. The handler then loads the export by export_id and returns a storage object, but the reviewed handler does not compare the export's actual project to the route project. Export IDs are opaque. A separate storage authorization policy exists, but the reviewer has not yet seen the effective production policy.
The supported observation is a missing comparison in this handler. It is not yet a verified cross-project download. The storage policy may enforce the missing boundary; the attacker may also need an export ID that ordinary users cannot obtain. Here is the path record:
| Step | Attacker must have or do | Evidence and status | Control or question | Effect on difficulty |
|---|---|---|---|---|
| 1. Start | Hold a legitimate account with membership in any project | Assumed actor for analysis; account creation policy not checked | Can an ordinary external customer obtain this role? | May be low friction, but is not “no privileges.” |
| 2. Enter | Call the download route with a project they can access | Route and middleware source reviewed | Does the gateway add another object check? | Route is plausible; deployed route still needs confirmation. |
| 3. Identify target | Supply a different project's valid export_id |
ID format observed; disclosure route not found in the reviewed scope | Is an ID exposed through notifications, logs, links, or predictable generation? | Decisive unknown; opaque does not mean unknowable. |
| 4. Cross boundary | Handler retrieves export by ID without comparing its project | Source-backed in the pinned handler | Does a shared helper or storage policy reject mismatch? | Missing handler check is supported; final bypass unresolved. |
| 5. Receive | Obtain report bytes from storage | No controlled validation done | What does the effective production storage policy authorize? | Outcome remains conditional. |
This table makes the next investigation obvious. The security engineer should inspect the effective storage policy and a full route-to-storage trace. The service owner should identify whether a valid foreign export ID can reach an ordinary user through normal features or permitted sharing. If either control blocks the path, record it. If both questions resolve in the attacker's favor, record the supported actor and path and have a second reviewer challenge the decisive evidence when the consequence warrants it. Even then, say source-supported path unless authorized runtime testing actually demonstrated the read.
Rank two supported paths after resolving the control
Continue the export exercise with supplied route and storage records: the affected route is enabled, storage uses a service identity without an end-user ownership decision, and the response returns the selected export. Assume independent verification and approval of that bounded flaw for this exercise. The missing handler comparison is now part of a supported path, rather than the entire proof.
Compare two deployments with the same export contents and missing comparison:
| Prerequisite | Customer-sharing deployment | Operator-only deployment |
|---|---|---|
| Entry access | Ordinary customer membership reaches the route. | Only the nominated export-operator role can invoke it. |
| Foreign export ID | A legitimate shared notification includes a different project's export ID. Its notification permission does not grant export download. | An operator can see export IDs in a permitted operations index; ordinary users cannot reach this index or the download route. |
| Final blocking control | None on the supplied path. | None after the operator gate on the supplied path. |
| Practical assessment | Lower difficulty for the ordinary-account actor: both entry and target knowledge are available through normal features. | Higher starting privilege requirement: the supported actor is an export operator. Once that role is held, the remaining operation is straightforward. |
The ranking is customer-sharing first for the stated ordinary-account threat. It does not mean the operator deployment has low impact or that the role is impossible to compromise. It means the operator role is the binding prerequisite in the evidence supplied. The table establishes a narrower eligible actor group, not how difficult that role is to obtain or compromise; assess role issuance and session controls separately before calling it hard to exploit. There is no numerical probability or benchmark behind the labels.
Do not add speculative ways to obtain the role merely to equalize the rows. “An attacker might steal an operator session” is a separate hypothesis unless evidence supports that path. Likewise, an opaque ID is no longer a difficulty barrier where a legitimate notification actually supplies it. Count the required facts, not the number of arrows in a diagram.
Reassess a feature change without changing the harm
The operator deployment later introduces a customer-facing shared-export notification. The new feature exposes foreign export IDs to ordinary members, but the download route still requires the operator role. Target knowledge has become easier; the entry gate still binds the supported actor. The overall ordinary-customer path remains blocked at that gate.
A second change grants ordinary members access to the download route. Now both prerequisites are satisfied: normal membership reaches the route and the notification supplies the ID. Reclassify practical difficulty for that actor and raise its work priority. The consequence—disclosure of another project's export—has not changed. Recording the two feature changes separately prevents the common mistake of treating ID disclosure alone as proof of a complete bypass.
The resulting update is: route grant R8 plus notification N3 removes the previously documented operator-only prerequisite; ordinary-member path now supported under the existing storage behavior. Reassess priority immediately and preserve the earlier operator-scoped record.
Look for prerequisites that are being counted twice
A long prerequisite list can exaggerate difficulty when several conditions arise from the same ordinary action. In the customer-sharing deployment, a customer who opens the normal notification already obtains the target export ID. Do not count “find the notification,” “read the ID” and “copy the ID” as three independent barriers. They describe one available information source.
Likewise, distinguish an entry requirement from a control that stops the harmful action. Login is a prerequisite for the export request. The missing object relationship is the authorization flaw. If ordinary customers can obtain the required login through the normal business process, the existence of authentication alone does not establish substantial practical difficulty. Record the actual account-acquisition conditions without speculating about stolen credentials.
A simple dependency sketch helps:
| Fact | Depends on | Independent barrier? |
|---|---|---|
| Ordinary account session | The product's account-entry policy | Yes, a starting-access condition whose difficulty needs evidence. |
| Foreign export identifier | Receipt of the shared notification | No additional discovery barrier once that notification is available. |
| Download route entry | Membership and the route's capability policy | A separate decision if it requires privileges beyond the ordinary account. |
| Report delivery | Selected export and downstream enforcement | A control/effect question, not just another user action. |
This sketch also avoids the opposite error: removing a prerequisite because it feels inconvenient. If the operator role remains mandatory, the ordinary-account path remains blocked there even after IDs become visible. The assessment must follow the actual conjunction of conditions, not a narrative about how easy the final request looks.
State what the difficulty label is relative to
“Lower difficulty” needs a comparison and an actor. In this article it compares two deployments of the same flaw for an ordinary external customer. It does not rank an operator insider, a compromised integration or a different attacker with another starting position. If those actors matter, create a separate row and preserve their distinct prerequisites.
For engineering planning, identify the prerequisite most likely to change soon. A planned role expansion or notification feature may remove a barrier before the fix is scheduled. Link the finding to that change so the owner reassesses it before rollout. This is a practical reason to prioritize a flaw even when today's actor set is narrow.
End the assessment with the evidence that would change the label. For the customer-sharing path, removing foreign IDs from notifications may change discovery effort while leaving the ownership defect. Enforcing the export's stored project before delivery changes the path itself. The two actions should not be reported as equivalent fixes.
A handoff that a developer can use
For the completed customer-sharing case, the handoff is: “An ordinary member can obtain a foreign export ID from the shared notification and use it on the reviewed download route. The route checks membership in the URL project; the handler and storage path do not bind the selected export to that project. Authorize the actual export before delivery and preserve legitimate same-project downloads.” Include the route, notification and storage references, not only the highlighted handler.
For the operator-only deployment, retain the same impact but name the export-operator prerequisite. The fix-verification plan belongs with the patch; this difficulty assessment should identify the facts that could change the ranking. Use the fix-verification guide for the subsequent closure work.
For your next alert, write the five-column path table before assigning a practical-difficulty label. If the distinction between a published score and the local path is still unclear, use the CVSS comparison guide. Use the full prioritization method when you need to turn the assessed path into a team queue.