authorization/testing

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

Authorization test matrix Actor-Resource-Action pattern

Define the application's access policy model using three components: Actor (the logical role or specific user attempting the operation, e.g., Tenant_Admin, Standard_User, Anonymous_User), Resource (the object or data being accessed, e.g., Invoice_123, /api/v2/users, System_Settings), and Action (the operation being performed, e.g., READ, CREATE, DELETE, EXECUTE).

Authorization test matrix machine-readable format

Store the authorization policy matrix in a machine-readable format (JSON, YAML, or structured test fixtures) rather than a spreadsheet. This allows testing frameworks to dynamically generate test cases and reduces manual maintenance as the authorization policy evolves.

YAML test fixture structure for authorization policies

Authorization test fixtures should include the following fields: resource (the API endpoint path), method (HTTP method like GET), owner_role (the role that owns the resource), allowed_roles (array of roles that should have access), denied_roles (array of roles that should be denied access), and expected_denial_code (HTTP status code for denied access, typically 403 Forbidden).

Horizontal privilege escalation (IDOR) regression test pattern

Implement the Multi-User Replay pattern to detect horizontal privilege escalation. Authenticate as User A and create a resource, capturing the resource identifier. Then authenticate as User B (same role, different account) and attempt to read, update, and delete the resource. The system must return HTTP 403 Forbidden or 404 Not Found, never 200 OK.

Vertical privilege escalation regression test pattern

Implement the Role Demotion Check pattern to detect vertical escalation. Build a suite of tests targeting administrative endpoints (e.g., /api/admin/users/delete). Iterate through all non-administrative roles (including unauthenticated users) and attempt to execute these endpoints. The API layer must explicitly reject the requests; relying on UI hiding is insufficient.

Multi-tenant data isolation regression test pattern

Implement the Cross-Tenant Boundary Test pattern to detect tenant isolation breakage. Provision two distinct tenants (Tenant Alpha and Tenant Beta) in the test environment. Seed data into Tenant Alpha. Execute broad read queries (e.g., GET /api/all-records) as a user from Tenant Beta. Assert that the response contains absolutely no records belonging to Tenant Alpha; even a single leaked record identifier constitutes a critical failure.

OpenAPI contract-driven authorization validation

Use the OpenAPI Specification securitySchemes and security fields to formally declare authorization requirements at both global and per-operation level. The OpenAPI definition should serve as the source of truth for authorization requirements. If an endpoint requires an OAuth2 scope of 'read:invoices', the testing framework should automatically verify that tokens lacking this scope receive a 401 Unauthorized or 403 Forbidden response.

API gateway middleware enforcement of OpenAPI security definitions

Configure API gateways or web frameworks to automatically enforce the security definitions present in the OpenAPI contract. Regression tests should validate that this middleware has not been bypassed or disabled following a refactor.

Authorization test framework recommendations

Use standard test runners for authorization suites: pytest for Python, Jest for JavaScript, JUnit for Java. This keeps the barrier to entry low and ensures the tests run in the same CI pipeline as functional tests.

Property-based testing tools for authorization APIs

Tools like Schemathesis or Dredd can read an OpenAPI specification and automatically generate negative test cases (e.g., requests without tokens, with expired tokens, or with tokens missing required scopes) to ensure the API fails securely.

Authorization test session switching without full login

Design the test suite to quickly and cheaply swap authentication context (e.g., swapping JWTs in the Authorization header as defined in RFC 6750) without requiring a full login flow for every test.

Authorization tests as required CI/CD pipeline check

The authorization test suite must be a required check in the CI/CD pipeline (e.g., GitHub Actions, GitLab CI). If an authorization test fails, the Pull Request cannot be merged.

Dedicated authorization test tagging for developer workflow

Tag or group authorization tests distinctly (e.g., @pytest.mark.authz or a dedicated authz-tests npm script). This allows developers to run them quickly and independently during local development.

CI environment monitoring for authorization failures

Configure CI environments to flag unusual volumes of HTTP 401 Unauthorized or 403 Forbidden responses during integration testing. These may indicate that a developer's functional changes are colliding with existing security controls.

Weak access control allows unauthorized system access

Weak or poorly implemented access control measures can allow unauthorized access to vehicle systems. For example, a driver might gain unauthorized access to administrative functions through a poorly secured mobile app.

Re-check ownership on every request

Re-check resource ownership on every request that acts on a resource. Do not rely on the URL, referrer, or a flag in the request body. The backend must verify on each independent request that the authenticated user is actually allowed to perform that action on that object, right now.

Never accept user ID or role from request body unless admin action

Never accept a user ID, tenant ID, or role from the request body unless the request is explicitly an administrative action by a privileged caller, and even then the value must be validated against what that caller is allowed to manage. The identity of the acting user must always come from server-side session or token, never from an editable field.

Contextual authorization: check state and relationship constraints

Check not just whether a user is authenticated and has a general role, but whether they can perform the specific action on this object in this state right now. Examples: a manager can approve expense reports but not their own; a reviewer can approve a pull request but not if they authored it; a user can cancel an order but not after it has shipped; a user can change their email but not to an address already in use.

Map sensitive operations to all entry points and verify rules at each

Map every sensitive operation to every entry point that can trigger it, including internal admin endpoints, new API versions, internal tools, and webhook handlers. Verify that each entry point enforces the same business rules. If two features logically grant the same permission, make sure both entry points are equally guarded.

Unit and integration testing for authorization logic

Unit and integration testing are essential for verifying that an application performs as expected and consistently across changes. Flaws in access control logic can be subtle, particularly when requirements are complex; even a small logical or configuration error in access control can result in severe consequences. Although not a substitution for dedicated security testing or penetration testing (see OWASP WSTG 4.5), automated unit and integration testing of access control logic can help reduce the number of security flaws in production. These tests catch 'low-hanging fruit' security issues but not more sophisticated attack vectors (OWASP SAMM: Security Testing).

Unit and integration test focus areas for authorization

Unit and integration testing should aim to incorporate concepts from authorization best practices. For example: (1) Is access being denied by default? (2) Does the application terminate safely when an access control check fails, even under abnormal conditions? (3) Are ABAC policies being properly enforced? While simple unit and integration tests can never replace manual testing by a skilled hacker, they are an important tool for detecting and correcting security issues quickly and with far fewer resources than manual testing.

Access Control Cheatsheet deprecated, use Authorization Cheatsheet

The OWASP Access Control Cheatsheet has been deprecated. Developers should refer to the Authorization Cheatsheet instead for current guidance on access control and authorization.

Give your agent this brain