Access control determines whether an authenticated identity may perform a requested operation on a particular API resource. Authentication establishes who is making the request; authorization checks what that identity may access. Identities can represent users, applications, services, or devices. section 7.1
Treat every endpoint and resource as protected, including APIs labeled internal. A private network or deployment assumption cannot replace authorization: configuration or deployment mistakes can expose sensitive operations and data. section 3.4 section 9.0
Check access control against the failure modes that commonly expose data or privileges:
- Prevent broken object-level authorization (BOLA) by validating every request against the requesting user’s permission for the target resource. section 4.2 section 4.11
- Prevent broken function-level authorization (BFLA) by evaluating permissions for every operation, not merely accepting an authenticated request. section 4.11 section 2.3.2
- Prevent broken object-property-level authorization (BOPLA) by constraining input, using strict data models, and checking which fields a user may read or change. section 4.11
- Require stronger controls for more sensitive data and operations, while applying authorization consistently across public and internal APIs. section 3.4
Two users, one protected resource
Suppose user B creates a blog post with ID 1. PUT /posts/1 should permit edits only for user B. If user A can update that post, the endpoint has BOLA. The same check applies to payment details, registrations, orders, and other resources linked to an account. A simple test creates users A and B, creates a resource for each, and verifies that A receives a denial when requesting B’s resource. section 4.2 section 2.3.2
Figure 2.7 Start testing your access controls with simple scenarios. Create two users, A and B. Make a payment with user A, and check whether user B has access to the details of user A’s payment.
Use the two-user payment scenario as a compact mental model: create a payment with user A, then check whether user B can view its details. section 2.3.2
Implement authorization with explicit permissions or roles, commonly carried in access tokens, and validate the token before evaluating access. Role-based controls distinguish ordinary and administrative operations; attribute-based controls can require a state such as a verified bank account. Document protected operations and keep the checks in automated tests. section 4.11 section 8.0 section 12.4
Build a repeatable verification checklist:
- Send unauthenticated, malformed, expired, or tampered-token requests to protected endpoints and expect rejection. section 12.4
- Use one user’s token to request another user’s resource and verify that the API denies access. section 12.4
- Use a normal user’s token against an administrative endpoint and verify that privilege escalation fails. section 12.4
- Run these checks on every change, fixing one endpoint at a time when a larger test suite feels difficult to complete. section 2.3.2
