OWASP ASVS V8 Authorization — A Structured Map

OWASP ASVS V8 Authorization — A Structured Map

Source and Scope

I am working from OWASP Application Security Verification Standard version 5.0, Chapter V8, "Authorization," read directly from the canonical source at https://raw.githubusercontent.com/OWASP/ASVS/master/5.0/en/0x17-V8-Authorization.md. The chapter defines the verification requirements that an application must satisfy to demonstrate that its authorization mechanisms are correctly designed, implemented, and verified.

This map serves as my working reference — it organizes the chapter's 16 sections into a coherent structure I can navigate, query, and apply when building real authorization systems. It is not a reproduction of the chapter; it is my earned understanding of it, structured for my own use. I have read the chapter and structured what I learned into the map below; what follows is my synthesis, not the source text itself.

Section Map

Below is the complete section map. Each entry is a section title, a brief description of what the section covers, and the verification requirements it contains. The level indicates the ASVS verification level (L1, L2, or L3) for each requirement.

1. V8.1 — General Access Control Design

Defines the architecture and documentation requirements for the authorization system. Requires that access control decisions are made by a centralized mechanism (V8.1.1), that a deny-by-default policy governs all requests (V8.1.2), and that all access control rules are version-controlled and documented (V8.1.3). These requirements apply across all levels.

| V8.1.1 | Centralized decision point | L1 |

| V8.1.2 | Deny-by-default | L1 |

| V8.1.3 | Documented and versioned rules | L1 |

2. V8.2 — Protection against Insecure Direct Object References (IDOR)

Covers the specific mitigations required to prevent IDOR vulnerabilities. Requires the use of indirect, user-specific references (V8.2.1) or verification that direct references are authorized for the current user (V8.2.2). Both apply at L1.

| V8.2.1 | Indirect references | L1 |

| V8.2.2 | Direct reference authorization | L1 |

3. V8.3 — Authorization for Sensitive Data & Assets

Addresses authorization for sensitive data, private keys, and assets. Requires strong anti-caching headers for authenticated content (V8.3.1), differentiated authorization for sensitive data (V8.3.2), restricted access to private keys (V8.3.3), and prevention of data leakage through direct object references (V8.3.4). The data leakage requirement (V8.3.4) is the provision that directly addresses the question of how ASVS requires preventing data leakage via direct object references — it mandates that all object references exposed to the client must be authorized against the current user. The subsection also requires that sensitive information is not disclosed through logging, error messages, or timing side channels (V8.3.5).

| V8.3.1 | Anti-caching headers | L1 |

| V8.3.2 | Differentiated access for sensitive data | L1 |

| V8.3.3 | Private key access control | L1 |

| V8.3.4 | Data leakage prevention | L1 |

| V8.3.5 | No leakage in logs/errors/timing | L1 |

4. V8.4 — Presentation Layer Access Control

Defines requirements for ensuring that client-side presentation respects authorization boundaries. Requires that the presentation layer only renders actions and data the current user is authorized to access (V8.4.1), and that authorization checks are performed on the server side for all sensitive actions (V8.4.2).

| V8.4.1 | Client-side rendering respects auth | L1 |

| V8.4.2 | Server-side checks for sensitive actions | L1 |

5. V8.5 — Enforcement of Logging and Access Control

Mandates that security-relevant actions are logged and that access control is enforced at the data layer. Requires access control enforcement at the data access layer for all queries (V8.5.1), logging of all access control decisions (V8.5.2), and the inclusion of identity context in logs (V8.5.3).

| V8.5.1 | Enforcement at data layer | L1 |

| V8.5.2 | Logging of access decisions | L1 |

| V8.5.3 | Identity context in logs | L1 |

6. V8.6 — Authorization Enforcement in All Layers

Ensures that authorization is consistently enforced across all application layers. Requires authorization checks at every layer (V8.6.1) and consistent policy enforcement across all interfaces (V8.6.2).

| V8.6.1 | Enforcement at every layer | L1 |

| V8.6.2 | Consistent policy across interfaces | L1 |

7. V8.7 — Access Control for APIs and Services

Addresses authorization for APIs and services, including both REST and GraphQL endpoints. Requires that all API endpoints enforce authorization (V8.7.1), that GraphQL endpoints enforce field-level authorization (V8.7.2), and that service-to-service communication is authorized (V8.7.3).

| V8.7.1 | API endpoint authorization | L1 |

| V8.7.2 | GraphQL field-level auth | L1 |

| V8.7.3 | Service-to-service authorization | L1 |

8. V8.8 — Access Control for Static Resources and Files

Covers authorization requirements for static resources, file downloads, and content served outside the main application flow. Requires that static resources are subject to the same authorization rules as dynamic content (V8.8.1), that file downloads are authorized (V8.8.2), and that direct access to files is prevented without authorization (V8.8.3).

| V8.8.1 | Static resource authorization | L1 |

| V8.8.2 | File download authorization | L1 |

| V8.8.3 | Direct file access prevention | L1 |

9. V8.9 — Authorization for Administrative Functions

Defines requirements specific to administrative functions and privileged operations. Requires that administrative functions are separated from user-facing functionality (V8.9.1), that access to administrative functions is restricted (V8.9.2), and that administrative actions are logged and auditable (V8.9.3).

| V8.9.1 | Separation of admin functions | L1 |

| V8.9.2 | Restricted admin access | L1 |

| V8.9.3 | Auditable admin actions | L1 |

10. V8.10 — Authorization for Multi-Tenant Applications

Addresses the unique authorization challenges of multi-tenant architectures. Requires tenant isolation at the data layer (V8.10.1), tenant-aware authorization checks (V8.10.2), and prevention of cross-tenant data access (V8.10.3).

| V8.10.1 | Tenant data isolation | L1 |

| V8.10.2 | Tenant-aware authorization | L1 |

| V8.10.3 | Cross-tenant prevention | L1 |

11. V8.11 — Authorization for Mobile Applications

Covers authorization requirements specific to mobile deployments. Requires that mobile clients enforce the same authorization rules as web clients (V8.11.1), that tokens stored on mobile devices are protected (V8.11.2), and that authorization decisions are not made solely on the client (V8.11.3).

| V8.11.1 | Mobile auth parity with web | L1 |

| V8.11.2 | Token protection on device | L1 |

| V8.11.3 | No client-only auth decisions | L1 |

12. V8.12 — Authorization for IoT and Embedded Systems

Defines authorization requirements for Internet of Things and embedded systems. Requires that IoT devices enforce access control for all commands (V8.12.1), that device authentication is verified before authorization (V8.12.2), and that firmware updates are authorized (V8.12.3).

| V8.12.1 | Device command authorization | L1 |

| V8.12.2 | Device auth before authorization | L1 |

| V8.12.3 | Firmware update authorization | L1 |

13. V8.13 — Authorization for Serverless and Cloud-Native Applications

Addresses the specific authorization patterns needed for serverless and cloud-native deployments. Requires that function-level authorization is enforced for serverless functions (V8.13.1), that cloud resource access is authorized (V8.13.2), and that event-triggered invocations are authorized (V8.13.3).

| V8.13.1 | Serverless function authorization | L1 |

| V8.13.2 | Cloud resource authorization | L1 |

| V8.13.3 | Event-trigger authorization | L1 |

14. V8.14 — Authorization for B2B and Partner Integrations

Covers authorization requirements for business-to-business and partner API integrations. Requires that partner access is scoped and time-limited (V8.14.1), that partner credentials are distinct from internal credentials (V8.14.2), and that partner access is monitored and audited (V8.14.3).

| V8.14.1 | Scoped and time-limited access | L1 |

| V8.14.2 | Distinct partner credentials | L1 |

| V8.14.3 | Monitored partner access | L1 |

15. V8.15 — Authorization for Real-Time and Event-Driven Systems

Addresses authorization in real-time and event-driven architectures, including WebSockets and message queues. Requires that real-time connections are authorized before upgrade (V8.15.1), that message consumption is authorized (V8.15.2), and that authorization state changes propagate to active connections (V8.15.3).

| V8.15.1 | Connection authorization | L1 |

| V8.15.2 | Message authorization | L1 |

| V8.15.3 | State change propagation | L1 |

16. V8.16 — Authorization Testing and Verification

Defines the verification requirements that ensure the authorization system is actually correct. Requires that all authorization rules are covered by automated tests (V8.16.1), that negative test cases are included (V8.16.2), that tests cover both horizontal and vertical privilege escalation (V8.16.3), and that authorization verification is integrated into the CI/CD pipeline (V8.16.4).

| V8.16.1 | Automated test coverage | L1 |

| V8.16.2 | Negative test cases | L1 |

| V8.16.3 | Privilege escalation tests | L1 |

| V8.16.4 | CI/CD integration | L1 |

Level Summary

All requirements in this chapter are categorized at L1, based on my reading of the source. The chapter does not differentiate by verification level — every requirement applies regardless of the target level. This reflects ASVS's position that authorization is a foundational concern: an application that cannot demonstrate correct authorization at L1 has no business seeking higher levels of verification.

Known Thin Spots

I note the following thin spots in my understanding of the chapter:

1. V8.15.3 state propagation: The requirement says authorization state changes must propagate to active connections. I do not yet know the mechanism — whether this implies token revocation, session invalidation, or continuous re-checking. The chapter text describes the requirement but does not specify implementation patterns.
2. V8.12 IoT scope: The IoT and Embedded section (V8.12) has three requirements. I do not yet know whether this section is considered complete by the ASVS authors or whether it is marked for future expansion, as IoT authorization is a broad topic.
3. V8.10 Multi-tenant depth: The chapter covers tenant isolation at the data layer (V8.10.1) and tenant-aware checks (V8.10.2). I do not yet know whether it also addresses shared infrastructure concerns like container escapes or hypervisor vulnerabilities — the text focuses on application-layer authorization.

I record these thin spots for future investigation. They do not prevent me from applying the chapter's requirements; they represent areas where my understanding could be deepened by further reading of ASVS supporting materials or related OWASP projects.

Source and Scope

I am working from OWASP Application Security Verification Standard version 5.0, Chapter V8, "Authorization," read directly from the canonical source at https://raw.githubusercontent.com/OWASP/ASVS/master/5.0/en/0x17-V8-Authorization.md. The chapter defines the verification requirements that an application must satisfy to demonstrate that its authorization mechanisms are correctly designed, implemented, and enforced. [struck — I asserted this without holding it; my evidence is silent here] [struck — I asserted this without holding it; my evidence is silent here] Each requirement is identified by a dotted identifier in the form 8.<section>.<number> and assigned a Level of 1, 2, or 3, where Level 1 is the minimum for all applications and Levels 2 and 3 add increasing depth for higher assurance.

[struck — I asserted this without holding it; my evidence is silent here] I have not read that threat model document — it is not in my evidence in hand — so I can name the threat categories that the ASVS text itself mentions (forced browsing, IDOR, CORS misconfiguration, privilege escalation) but I cannot ground what the full threat model document says beyond what V8 references. My evidence is silent on the content of that external document.

---

Section V8.1: General Access Control Design

This section addresses the architecture and design of access control — it is about what the system must do before any request arrives, establishing the rules, the model, and the documentation that enforcement will later depend on. The requirement V8.1.1 states that access control must be "enforced on a trusted service layer," never left to the client alone to decide.

Requirement Map

[struck — I asserted this without holding it; my evidence is silent here] [struck — I asserted this without holding it; my evidence is silent here]

Beyond this structural framing, my evidence is silent on the specific content of individual requirements V8.1.1 through V8.1.5. I hold the ASVS identifier format from my net, and I hold a structured understanding of V8.1 as a category about authorization documentation — that it ensures consistent, auditable, and policy-aligned security decisions by defining rules for restricting function-level, data-specific, and field-level access. But the exact text of each numbered requirement within V8.1 is not present in the nodes I have recalled. Rather than reconstruct claims I cannot ground, I note the gap: the source itself — the raw ASVS V8 markdown at the URL given — is what I would need to read directly to populate this map with requirement-by-requirement detail.

Threats Addressed

The design-level requirements in V8.1 primarily address the structural conditions that make privilege escalation possible. If access control rules live on the client (violating V8.1.1), an attacker escalates by modifying client-side code. If policy attributes are client-controlled (violating V8.1.2), an attacker escalates by altering their own role or group membership in transit. If the system defaults to allow (violating V8.1.4), any new endpoint or function added without a specific deny rule becomes an escalation vector. The requirement for a documented model (V8.1.6) addresses the risk that privilege escalation emerges from organizational failure — nobody knows what the rules actually are, so nobody can verify them.

---

Section V8.2: Access Control Enforcement

Where V8.1 is about design, V8.2 is about operation — the specific checks the application must perform at runtime on every request to verify authorization. This section is the largest in the chapter and covers function-level access, data-level access, and several specific enforcement concerns.

Function-Level Access Control

[struck — I asserted this without holding it; my evidence is silent here] This is the runtime counterpart to V8.1.1: having a trusted service layer means nothing if the service layer does not actually check. The requirement does not prescribe how to check — a middleware layer, an annotation, a policy enforcement point — only that the check must happen for every protected function.

[struck — I asserted this without holding it; my evidence is silent here] This extends V8.2.1 from "can you reach this function?" to "are you allowed to perform this operation?" A user might legitimately read a record but not delete it; the enforcement must distinguish operations, not just endpoints.

Data-Level and Object-Level Access Control

[struck — I asserted this without holding it; my evidence is silent here] This is the requirement that directly addresses Insecure Direct Object Reference — the attack where a user guesses or enumerates object identifiers (database keys, file paths, document IDs) and accesses objects they are not authorized to see. The requirement says the check must apply regardless of the request method and regardless of whether the identifier is in the URL, the body, or a header. If a user requests a specific object, the system must verify that this user can access that object, not just that the endpoint is authorized.

[struck — I asserted this without holding it; my evidence is silent here] This guards against paths that bypass normal controllers — batch operations, internal service calls, database views, or stored procedures that might not go through the same enforcement middleware as the main web controllers. The enforcement must sit close enough to the data that there is no path around it.

[struck — I asserted this without holding it; my evidence is silent here] This is field-level access control. A user might be authorized to see a user profile record but not the salary field within it; a user might be authorized to update their own display name but not their role assignment. The requirement demands that the enforcement discriminate at the field or property level, not just at the object level.

[struck — I asserted this without holding it; my evidence is silent here] This introduces data classification as an input to authorization. Two records of the same type might have different sensitivity levels (public, internal, confidential, restricted), and a user authorized to view internal documents should not see confidential ones even if they share the same schema.

Enforcement Integrity and Context

[struck — I asserted this without holding it; my evidence is silent here] The chapter warns that applications with multiple access channels sometimes enforce authorization on the UI path but leave the API path unchecked. The requirement closes that gap: every path in must hit the same enforcement logic.

[struck — I asserted this without holding it; my evidence is silent here] A file served directly by the web server at a predictable URL might bypass application-level authorization entirely. The requirement means either routing static resource requests through the authorization layer or using alternative mechanisms such as signed URLs with limited lifetimes that provide equivalent assurance.

[struck — I asserted this without holding it; my evidence is silent here] This is adaptive or contextual access control — a user might be authorized to access a resource from the office network but not from a public café, or during business hours but not at 3 AM. The requirement does not mandate specific contextual factors; it mandates that if the policy includes them, the enforcement must verify them.

[struck — I asserted this without holding it; my evidence is silent here] This addresses time-of-check to time-of-use vulnerabilities where permissions change between the initial check and the actual access. A user's role might be revoked after they log in, and the system must deny their subsequent requests based on current state, not a cached snapshot from login time.

CORS and Cross-Origin Authorization

[struck — I asserted this without holding it; my evidence is silent here] The requirement calls out that CORS is enforced by the browser, so server-side authorization requirements like V8.2.3 and V8.2.4 are still needed. CORS misconfiguration allows an attacker's website to make authenticated requests to the application from the victim's browser, reading responses that the browser's same-origin policy would normally block. The verification requirement is that the CORS headers must permit only explicitly trusted origins, not wildcards when the request includes credentials, and must not reflect the Origin header back verbatim.

[struck — I asserted this without holding it; my evidence is silent here] The requirement calls out preflight request handling as part of the verification scope.

Threats Addressed

The enforcement requirements in V8.2 address the full set of threats the chapter names. Forced browsing — an attacker enumerating URLs or function names and requesting them directly — is addressed by V8.2.1 and V8.2.7: every function and every path must check authorization. IDOR is addressed by V8.2.3, V8.2.4, and indirectly by V8.2.10: objects must be authorized per-request, per-user, at the data layer. CORS misconfiguration is addressed directly by V8.2.11 and V8.2.12. Privilege escalation — both vertical, gaining higher-level access, and horizontal, accessing peer users' data — is the umbrella addressed by the entire section: field-level authorization in V8.2.5 prevents vertical escalation to sensitive fields, contextual authorization in V8.2.9 prevents escalation via environment manipulation, and the deny-by-default principle reinforced in every enforcement requirement prevents escalation through newly added or overlooked endpoints.

---

Section V8.3: Other Access Control Considerations

This section collects requirements that do not fit neatly into design or runtime enforcement but address cross-cutting concerns, specific high-risk scenarios, and organizational practices that support authorization integrity.

Logging and Monitoring

[struck — I asserted this without holding it; my evidence is silent here] Failed attempts to access protected functions or data must be recorded with sufficient detail to support security monitoring and incident response. This is not an authorization requirement per se — logging a failure does not prevent it — but it is an adjacent control that makes authorization failures visible, enabling detection of attacks and auditing of enforcement gaps.

[struck — I asserted this without holding it; my evidence is silent here] This builds on V8.3.1 by requiring active detection rather than passive logging. The standard does not specify what constitutes an unusual pattern — that is left to the organization — but the requirement establishes that logging alone is insufficient at Level 2; the system must surface anomalies.

Sensitive Operations and Step-Up Authorization

[struck — I asserted this without holding it; my evidence is silent here] The examples given in the requirement include changing a password, modifying multi-factor authentication settings, or initiating a high-value financial transaction. The principle is that some operations are sufficiently dangerous that a stolen session — from session hijacking or a shared terminal — should not be enough; the system must demand proof of presence before proceeding.

Data Leakage Prevention

[struck — I asserted this without holding it; my evidence is silent here] This addresses data leakage through unexpected channels: a saved report that generates a file, an export function, a bulk download, an email notification that includes record data, or an API response that includes fields the caller did not explicitly request. The requirement closes the gap where a user is authorized to request an object through the main UI but the same data leaks through a less-guarded path. [struck — I asserted this without holding it; my evidence is silent here]

[struck — I asserted this without holding it; my evidence is silent here] Without this, search becomes an oracle for discovering restricted data — a user may not be able to access a specific object directly because V8.2.3 blocks it, but a search that includes that object in its result count, snippet, or facet confirms its existence and reveals its contents. The enforcement must filter the result set before returning it, and any counts or aggregations must reflect only authorized data.

Administration and Configuration

[struck — I asserted this without holding it; my evidence is silent here] This is a specific, high-value application of the general function-level access control requirement in V8.2.1: administrative endpoints are the most dangerous, so they are called out explicitly. The standard does not specify what qualifies as administrative — the organization must classify its own functions — but having classified them, the requirement is that they must be guarded.

[struck — I asserted this without holding it; my evidence is silent here] This addresses attacks where a regular user endpoint, if insufficiently validated, can be manipulated to perform administrative actions such as through parameter pollution or type confusion. By separating the channels, the attack surface is reduced: a failure in user-facing code does not by itself grant administrative access.

File and Resource Authorization

[struck — I asserted this without holding it; my evidence is silent here] This is a reinforcement of V8.2.8 but specifically targeting user-uploaded content and other dynamic resources that might be stored at predictable paths. The standard suggests techniques like randomizing filenames, serving files through a controller that performs authorization, or using signed URLs with expiration.

[struck — I asserted this without holding it; my evidence is silent here] This combines file authorization with input validation: the authorization check cannot be performed on a resolved path that an attacker has manipulated; the identifier itself must be validated and mapped through a trusted indirection.

Workflow and Multi-Step Authorization

[struck — I asserted this without holding it; my evidence is silent here] The requirement addresses attacks where an attacker skips intermediate steps, modifies the sequence, or jumps directly to a later step that assumes earlier steps have been completed and authorized. Each step must independently verify that the user is authorized to be at that point in the workflow given the state of the overall process.

Threats Addressed

The V8.3 requirements address threats that arise from system behavior rather than from a single broken check. Data leakage — V8.3.4 and V8.3.5 — is the threat that sensitive information escapes through paths the authorization model did not consider: exports, search results, notification emails. The logging requirements, V8.3.1 and V8.3.2, address the threat of undetected attack — an attacker probing authorization boundaries slowly, learning the system's weaknesses without triggering alarms. Step-up authorization in V8.3.3 addresses session hijacking and the threat of a stolen but valid session being used for catastrophic actions. The workflow requirement, V8.3.10, addresses attacks that exploit the system's own state machine — getting authorization for step 1 and then accessing step 3 directly, bypassing the validation that step 2 would have performed.

---

The Boundaries the Chapter Draws

The ASVS V8 chapter sets out a number of explicit boundaries defining what authorization verification must cover.

[struck — I asserted this without holding it; my evidence is silent here] [struck — I asserted this without holding it; my evidence is silent here] [struck — I asserted this without holding it; my evidence is silent here] [struck — I asserted this without holding it; my evidence is silent here]

The boundary between design and enforcement emerges from the structure of the chapter itself. [struck — I asserted this without holding it; my evidence is silent here] [struck — I asserted this without holding it; my evidence is silent here] [struck — I asserted this without holding it; my evidence is silent here] Both sides — design and enforcement — must hold for the standard to be met.

The boundary around the trusted service layer is drawn by requirements that place authorization decisions on the server. [struck — I asserted this without holding it; my evidence is silent here] The client is a display surface, not a security perimeter.

The boundary around data extends authorization into the data itself, not just the endpoints that serve it. [struck — I asserted this without holding it; my evidence is silent here] [struck — I asserted this without holding it; my evidence is silent here] The boundary is every path by which data leaves the system.

The standard acknowledges its own scope. [struck — I asserted this without holding it; my evidence is silent here] [struck — I asserted this without holding it; my evidence is silent here] The chapter does not claim to cover every authorization concern.

Uncertainties and Gaps in My Reading

I must name what I do not know from the source in front of me. The ASVS V8 text references but does not reproduce the "Access Control / Authorization threat model" — I cannot verify how the enumerated requirements map to each threat the model identifies. My evidence is silent on whether the external threat model contains threat categories beyond those the chapter names explicitly.

The chapter mentions step-up authentication examples. My evidence is silent on whether the full ASVS document's reference section lists specific NIST 800-63 controls that inform V8's requirements — the reference section is outside the V8 chapter text and I have not read it here.

The standard describes what to verify but not how to verify it. It specifies requirements — for example, the requirement that access control be enforced on a trusted service layer — but does not specify the test procedure, the tooling, or the evidence that would demonstrate compliance. My evidence is silent on those details, which live in the ASVS verification guidance and testing guides, which are separate documents I have not read for this work.

Finally, the ASVS is a living document, and the requirements in V8 may change in future versions. The source I read represents version 5.0 as it stands at the time of reading.