asvs/v8-authorization

17 notes, read out of this brain and free to use. Each one was extracted from a source and is re-checked against its exam.

V8.1.1 Authorization Documentation - Function and Data-Level Access

Requirement 8.1.1 at Level 1 requires verification that authorization documentation defines rules for restricting function-level and data-specific access based on consumer permissions and resource attributes.

V8.1.2 Authorization Documentation - Field-Level Access Restrictions

Requirement 8.1.2 at Level 2 requires verification that authorization documentation defines rules for field-level access restrictions for both read and write operations based on consumer permissions and resource attributes. These rules may depend on other attribute values of the data object, such as state or status.

V8.1.3 Environmental and Contextual Attributes in Authorization Documentation

Requirement 8.1.3 at Level 3 requires verification that the application's documentation defines the environmental and contextual attributes used in security decisions, including time of day, user location, IP address, or device. This includes attributes used in authentication and authorization decision-making.

V8.1.4 Authorization Documentation - Environmental and Contextual Factors in Decision-Making

Requirement 8.1.4 at Level 3 requires verification 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. Documentation must include the attributes evaluated, thresholds for risk, and actions taken such as allow, challenge, deny, or step-up authentication.

V8.2.1 Function-Level Access Control

Requirement 8.2.1 at Level 1 requires verification that the application ensures function-level access is restricted to consumers with explicit permissions.

V8.2.2 Data-Specific Access Control - IDOR and BOLA Prevention

Requirement 8.2.2 at Level 1 requires verification that the application ensures data-specific access is restricted to consumers with explicit permissions to specific data items. This mitigates insecure direct object reference (IDOR) and broken object level authorization (BOLA) vulnerabilities.

V8.2.3 Field-Level Access Control - BOPLA Prevention

Requirement 8.2.3 at Level 2 requires verification that the application ensures field-level access is restricted to consumers with explicit permissions to specific fields. This mitigates broken object property level authorization (BOPLA) vulnerabilities.

V8.2.4 Adaptive Security Controls Based on Environmental and Contextual Attributes

Requirement 8.2.4 at Level 3 requires verification that adaptive security controls based on environmental and contextual attributes (such as time of day, location, IP address, or device) are implemented for authentication and authorization decisions as defined in documentation. These controls must be applied both when starting a new session and during an existing session.

V8.3.1 Authorization Enforcement at Trusted Service Layer

Requirement 8.3.1 at Level 1 requires verification that the application enforces authorization rules at a trusted service layer and does not rely on controls that an untrusted consumer could manipulate, such as client-side JavaScript.

V8.3.2 Immediate Authorization Changes Application

Requirement 8.3.2 at Level 3 requires verification that changes to values on which authorization decisions are made are applied immediately. Where immediate application is not possible, such as when relying on data in self-contained tokens, mitigating controls must alert when a consumer performs an action while no longer authorized and revert the change. This alternative does not mitigate information leakage.

V8.3.3 Object Access Based on Subject Permissions, Not Intermediary Permissions

Requirement 8.3.3 at Level 3 requires verification that access to an object is based on the originating subject's (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, and that service requests data from another service, the second service must use the consumer's token for permission decisions rather than a machine-to-machine token from the first service.

V8.4.1 Multi-Tenant Cross-Tenant Controls

Requirement 8.4.1 at Level 2 requires verification 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.

V8.4.2 Administrative Interface Access Controls

Requirement 8.4.2 at Level 3 requires verification that access to administrative interfaces incorporates multiple layers of security, including continuous consumer identity verification, device security posture assessment, and contextual risk analysis. Network location or trusted endpoints must not be the sole authorization factors, although they may reduce the likelihood of unauthorized access.

V8 Authorization Control Objective

V8 Authorization ensures that access is granted only to permitted consumers (users, servers, and other clients) by enforcing the Principle of Least Privilege (POLP). Verified applications must document authorization rules including decision-making factors and environmental contexts, and ensure consumers have access only to resources permitted by their defined entitlements.

GraphQL authorization recommendation

When using GraphQL, implement authorization logic at the business logic layer instead of the GraphQL or resolver layer to avoid having to handle authorization on every separate interface. This is an in-scope recommendation for ASVS 5.0.

Single access control mechanism principle

Ideally, a single access control mechanism should be used to access protected data and resources. All requests should pass through this single mechanism to avoid copy and paste or insecure alternative paths. This is a software security principle from ASVS 5.0.

Attribute-based access control pattern recommendation

Attribute or feature-based access control is a recommended pattern whereby the code checks the user's authorization for a feature or data item rather than just their role. Permissions should still be allocated using roles. This is a software security principle from ASVS 5.0.

Give your agent this brain