API Authorization Boundary Tester
Test who may perform which action on whose resource without probing uncontrolled data.
Inputs and evidence
Require written authorization to test, an approved environment, the access-control policy,
principal and role definitions, resource ownership rules, and controlled test identities.
Mark policy gaps Unknown; never infer permissions from role names.
Workflow
- Inventory principals, roles, scopes, tenants, resources, ownership, and actions.
- Derive expected allow or deny outcomes only from the supplied policy.
- Define isolated synthetic fixtures owned by each approved test principal.
- Cover cross-role, cross-owner, cross-tenant, and insufficient-scope boundaries without
enumerating unknown identifiers.
- Verify response, exposed data, absence of unauthorized mutation, and documented audit evidence.
- HUMAN REVIEW GATE (mandatory). Require approval of identities, fixtures, endpoints,
request limits, evidence handling, and cleanup before sending any request.
Output shape
| Principal |
Resource owner or tenant |
Action |
Policy expectation |
Assertions |
Evidence |
Include authorization scope, unknown policy rules, cleanup, and review decision.
Guardrails
- Never brute-force, enumerate real IDs, access uncontrolled records, or test outside scope.
- Default to isolated non-production environments and synthetic resources.
- Do not invent whether denial returns
401, 403, or 404; follow the contract.
- Redact credentials and sensitive values; report exposed data with the minimum evidence needed.
- Never claim a vulnerability from a hypothetical case or an unexecuted request.
1---2name: api-authorization-boundary-tester3description: Design safe API authorization-boundary tests across roles, scopes, tenants, and object ownership. Use when asked to test BOLA or IDOR risks, tenant isolation, cross-user access, privilege boundaries, or whether a principal may act on a resource. Produce a policy-backed access matrix using controlled synthetic fixtures.4license: MIT5---67# API Authorization Boundary Tester89Test who may perform which action on whose resource without probing uncontrolled data.1011## Inputs and evidence1213Require written authorization to test, an approved environment, the access-control policy,14principal and role definitions, resource ownership rules, and controlled test identities.15Mark policy gaps `Unknown`; never infer permissions from role names.1617## Workflow18191. Inventory principals, roles, scopes, tenants, resources, ownership, and actions.202. Derive expected allow or deny outcomes only from the supplied policy.213. Define isolated synthetic fixtures owned by each approved test principal.224. Cover cross-role, cross-owner, cross-tenant, and insufficient-scope boundaries without23 enumerating unknown identifiers.245. Verify response, exposed data, absence of unauthorized mutation, and documented audit evidence.256. **HUMAN REVIEW GATE (mandatory).** Require approval of identities, fixtures, endpoints,26 request limits, evidence handling, and cleanup before sending any request.2728## Output shape2930| Principal | Resource owner or tenant | Action | Policy expectation | Assertions | Evidence |31|---|---|---|---|---|---|3233Include authorization scope, unknown policy rules, cleanup, and review decision.3435## Guardrails3637- Never brute-force, enumerate real IDs, access uncontrolled records, or test outside scope.38- Default to isolated non-production environments and synthetic resources.39- Do not invent whether denial returns `401`, `403`, or `404`; follow the contract.40- Redact credentials and sensitive values; report exposed data with the minimum evidence needed.41- Never claim a vulnerability from a hypothetical case or an unexecuted request.
PramodDutta