Authorization Testing
Authorization testing systematically verifies every role-against-resource combination — not just that unauthorized requests fail, but that no role gains unintended reach through nested and bulk paths.
Definition
Authorization testing is the systematic matrix verification of access decisions: for each role and each protected operation, assert allow or deny matches policy. It covers direct requests, nested resource paths, bulk endpoints, and administrative surfaces. It differs from authentication testing, which checks who you are rather than what you may do.
Context and scope
Encoded as permission matrix tests in API suites, authorization-aware property tests generating role-resource pairs, and audit gates on route inventories. OWASP WSTG formalizes the methodology.
Common misconceptions
- Testing that admin works and anonymous fails is enough — the escapes live between roles: editor reaching auditor data, tenant A touching tenant B
- Authorization is enforced at the controller, so one test per controller is enough — service and repository layers, background jobs, and GraphQL resolvers each re-expose the decision
- Adding a role means updating tests manually — generate the matrix from the policy definition so new roles inherit full coverage automatically
Anti-patterns
- Asserting 403 on one endpoint per role and shipping reachability through bulk and nested paths
- Testing authorization only on the API layer while queue consumers and cron jobs run with god-mode credentials
- Generating matrix tests from the code instead of the policy, so the tests agree with the bug
Related concepts
Related examples
Authoritative source
What it is
Access control bugs do not crash — they return the wrong data with a success code. Testing them requires asking the negative question at scale: for every role, which requests must fail.
How it works
Derive the matrix from policy as data: roles times operations times resource scopes. Each cell executes the request with that principal and asserts the expected status and payload absence. Property-based variants generate randomized role-resource pairs. Coverage of the route inventory is itself asserted — every route appears in the matrix.
When to run
On every change to policy, roles, or routes, and as a scheduled audit — authorization regressions are silent and cumulative. Include internal surfaces: admin panels, internal tooling, job runners.
Pitfalls
The matrix from code replicates implementation, not intent — generate from declared policy and review diffs of the policy itself. Positive tests passing says nothing about negative space. Performance-sensitive endpoints sometimes bypass centralized checks for speed — the bypass needs its own test.