Pentest Advanced Access Control Auditor

Advanced Access-Control Auditor

Purpose

Identify and validate authorization failures without relying on UI-only evidence or unsafe impact demonstrations.

Use When

• The owner phase is IDOR, BOLA, BFLA, RBAC, object ownership, function authorization, cross-tenant access, or privilege boundary testing.
• A role matrix, session set, resource map, or privileged operation is available.
• The task needs deterministic proof that one actor can access or perform something outside its expected boundary.

Inputs

• Target URL or API route group.
• Role matrix with controlled test users or service identities.
• Resource map with owned, foreign, tenant-separated, and synthetic object IDs.
• Expected permission matrix for actions such as read, create, update, approve, export, or administrative operation.

Workflow

1. Define the expected role-to-resource-to-action matrix before testing.
2. Build positive controls where the rightful owner or role is allowed.
3. Build negative controls where a lower role, peer user, or other tenant should be denied.
4. Test horizontal, vertical, object-level, function-level, workflow-level, and tenant boundaries.
5. Compare alternate methods, alternate objects, alternate roles, and direct API calls when they change the trust boundary.
6. Capture exact requests, responses, status, object markers, timestamps, and identity context.
7. Hand off only confirmed primitives for chaining or reporting.

Verification Gate

• Confirm with paired-role testing and at least one negative control.
• Use controlled test accounts, owned objects, or synthetic non-sensitive objects.
• Prove data exposure with minimal redacted fields or test markers, not bulk data retrieval.
• Prove state changes with reversible, non-destructive changes where possible.
• Do not infer authorization from UI visibility alone.

Common Test Primitives

• IDOR/BOLA: swap object IDs between controlled users or tenants and compare expected deny versus observed access.
• BFLA: call a privileged function from a lower-privilege role using a harmless operation or dry-run endpoint when available.
• Method tampering: compare GET, POST, PUT, PATCH, and DELETE only where the action is reversible and in scope.
• Parameter pollution: compare single-value and multi-value parameters with clear expected parsing behavior.
• Metadata abuse: use exposed OpenAPI, OData, GraphQL, WSDL, or RPC definitions to identify hidden functions, then validate authorization with controls.

Handoff Criteria

• Hand off to pentest-authentication-authorization-review when session integrity, token lifecycle, MFA, or authentication behavior is the main blocker.
• Hand off to pentest-input-protocol-manipulation when parser behavior or HTTP semantics become the owner phase.
• Hand off to pentest-business-logic-abuse when the boundary depends on workflow state or sequencing.
• Hand off to pentest-evidence-structuring-report-synthesis when proof is complete.

Output

• Access-control matrix: actor, resource, action, expected, observed, evidence.
• Confirmed boundary breaks with attacker capability, preconditions, impact, and controls.
• Reproduction steps using controlled accounts and minimal proof data.