SolutionsWho We HelpHow We TestPricingWhy PocForgeResearchTalk to a Pentester ↗
POCFORGE RESEARCH 16 MIN READTECHNICAL DEEP DIVE OFFENSIVE SECURITY

API Authorization Attack Chains: From BOLA to Cross-Tenant Impact

A deep-dive methodology for validating API authorization boundaries, chaining object-level and function-level access control failures, and measuring tenant impact safely.

Broken object-level authorization is rarely just an id=1002 problem. In a mature API assessment, the important question is whether the server consistently derives authorization from the authenticated principal, the object, the tenant and the requested action. OWASP identifies Broken Object Level Authorization as API1:2023 and recommends considering object-level checks in every function that uses a client-supplied object identifier. OWASP API Security Top 10.

Core testing principleNever ask only “Can I change the ID?” Ask “What authorization decision should happen here, what context should influence it, and can I prove that the server enforced it?”

1. Model the authorization boundary

Start by mapping principals, tenants, objects and actions. A useful model is subject → action → object → tenant → policy. For each API family, identify which fields are security-sensitive and whether the server can derive them independently.

Dimension Questions Evidence
Subject Which user, service or role is authenticated? Token/session context
Object Who owns the resource? Object metadata
Tenant Which organization contains it? Tenant mapping
Action Is read different from update/delete? HTTP method + endpoint

2. Build an object map

Capture identifiers from URLs, JSON bodies, nested resources, GraphQL variables, filters and export endpoints. UUIDs and opaque IDs reduce casual guessing but do not replace authorization. The test is whether a principal can access an object they are not entitled to access.

Authorization decision simulator

Select the context to see what a secure server should do.

Allow when the authenticated principal is authorized for the object and action.

3. Look for chains, not isolated requests

A low-privileged read may become more serious when combined with update, export, password-reset, invite or administrative endpoints. Test the same object across GET, PATCH, DELETE, bulk endpoints and nested resources. Then compare behavior across roles and tenants.

GET    /api/accounts/1002
PATCH  /api/accounts/1002
DELETE /api/accounts/1002
POST   /api/accounts/1002/export

For GraphQL, repeat the exercise with node IDs, resolver arguments, nested relationships and mutations. The objective is to identify inconsistent enforcement between resolvers.

4. Measure impact

Record the minimum privilege required, number and type of affected objects, whether the issue crosses a tenant boundary, and whether write actions are possible. Avoid broad extraction: demonstrate the smallest amount of data or state change needed to prove the boundary failure.

01Authenticated principal
02Unauthorized object
03Server decision

5. Defensive design

Centralize authorization decisions where practical, enforce ownership or tenant constraints server-side, and test authorization at the service layer rather than trusting client-supplied tenant or owner fields. Add automated authorization tests for each sensitive object type and action.

Pentest checklist

  1. Map object identifiers and ownership.
  2. Build a role × action × object matrix.
  3. Test read, write, delete and export paths.
  4. Repeat across tenants and nested resources.
  5. Check bulk and batch endpoints.
  6. Check GraphQL queries and mutations.
  7. Document the smallest reproducible proof.