ASVS 5.0 V8 Authorization

V8.1.1 Level 1

Verify that authorization documentation defines rules for restricting function-level and data-specific access based on consumer permissions and resource attributes.

V8.1.2 Level 2

Verify that authorization documentation defines rules for field-level access restrictions (both read and write) based on consumer permissions and resource attributes. Note that these rules might depend on other attribute values of the relevant data object, such as state or status.

V8.1.3 Level 3

Verify that the application's documentation defines the environmental and contextual attributes (including but not limited to, time of day, user location, IP address, or device) that are used in the application to make security decisions, including those pertaining to authentication and authorization.

V8.1.4 Level 3

Verify that authentication and authorization documentation defines how environmental and contextual factors are used in decision-making, in addition to function-level, data-specific, and field-level authorization. This should include the attributes evaluated, thresholds for risk, and actions taken (e.g., allow, challenge, deny, step-up authentication).

V8.2.1 Level 1

Verify that the application ensures that function-level access is restricted to consumers with explicit permissions.

On this site: Authorize functions and fields as well as objects (guide) · Authenticate workloads and authorize their service actions (guide) · Authorization models: RBAC, ABAC, ReBAC and policy as code you can test (guide)

V8.2.2 Level 1

Verify that the application ensures that data-specific access is restricted to consumers with explicit permissions to specific data items to mitigate insecure direct object reference (IDOR) and broken object level authorization (BOLA).

On this site: Enforce authorization for every object action (guide) · Review a code change through its trust boundaries (guide) · Authorization models: RBAC, ABAC, ReBAC and policy as code you can test (guide) · Keep retrieval inside the user’s data boundary (guide) · Constrain MCP and multi-agent trust boundaries (guide) · Defend agent memory and context against poisoning (OWASP ASI06) (guide) · Case study: First American's EaglePro document exposure (2019) (guide)

V8.2.3 Level 2

Verify that the application ensures that field-level access is restricted to consumers with explicit permissions to specific fields to mitigate broken object property level authorization (BOPLA).

On this site: Authorize functions and fields as well as objects (guide) · Authorization models: RBAC, ABAC, ReBAC and policy as code you can test (guide) · Mass assignment (over-posting) (fix card)

V8.2.4 Level 3

Verify that adaptive security controls based on a consumer's environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions, as defined in the application's documentation. These controls must be applied when the consumer tries to start a new session and also during an existing session.

V8.3.1 Level 1

Verify that the application enforces authorization rules at a trusted service layer and doesn't rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript.

On this site: Enforce authorization for every object action (guide) · Contain prompt injection at the application boundary (guide) · Review trust boundaries in mobile and native clients (guide) · Review a code change through its trust boundaries (guide) · Authorization models: RBAC, ABAC, ReBAC and policy as code you can test (guide) · Authorize agent tools outside the model (guide) · Keep secrets and controls out of hidden context (OWASP LLM08:2026) (guide) · Case study: First American's EaglePro document exposure (2019) (guide) · Missing authentication for a critical function (fix card)

V8.3.2 Level 3

Verify that changes to values on which authorization decisions are made are applied immediately. Where changes cannot be applied immediately, (such as when relying on data in self-contained tokens), there must be mitigating controls to alert when a consumer performs an action when they are no longer authorized to do so and revert the change. Note that this alternative would not mitigate information leakage.

On this site: Authorize agent tools outside the model (guide) · Contain cascading failures and rogue agents (guide) · SCIM deprovisioning: make account disablement remove every usable authority (guide)

V8.3.3 Level 3

Verify that access to an object is based on the originating subject's (e.g. consumer's) permissions, not on the permissions of any intermediary or service acting on their behalf. For example, if a consumer calls a web service using a self-contained token for authentication, and the service then requests data from a different service, the second service will use the consumer's token, rather than a machine-to-machine token from the first service, to make permission decisions.

On this site: Authorization models: RBAC, ABAC, ReBAC and policy as code you can test (guide)

V8.4.1 Level 2

Verify that multi-tenant applications use cross-tenant controls to ensure consumer operations will never affect tenants with which they do not have permissions to interact.

On this site: Enforce authorization for every object action (guide) · Review tenant boundaries before implementation (guide) · Authorization models: RBAC, ABAC, ReBAC and policy as code you can test (guide) · Keep retrieval inside the user’s data boundary (guide) · SCIM deprovisioning: make account disablement remove every usable authority (guide)

V8.4.2 Level 3

Verify that access to administrative interfaces incorporates multiple layers of security, including continuous consumer identity verification, device security posture assessment, and contextual risk analysis, ensuring that network location or trusted endpoints are not the sole factors for authorization even though they may reduce the likelihood of unauthorized access.