Direct answer
Access control testing checks whether the server applies the application's permission rules to each protected action. Begin with a matrix of roles, resources, and operations, then test both allowed and forbidden combinations through the underlying API.
Write the policy before the test
Authentication establishes who the caller is; authorization decides what that caller may do. Document the intended permissions for roles such as viewer, editor, administrator, and service account. Include object ownership and tenant membership where the same role has different rights over different data.
Reference: OWASP Authorization Cheat Sheet.
Test the server behind the interface
A hidden settings button tells you how the interface behaves, but says little about the endpoint. In a test workspace, send the corresponding request as a role that should be denied. Keep the administrator's valid request as a comparison.
- List actions separately: read, create, update, export, and delete.
- Include direct routes, bulk operations, and alternate HTTP methods.
- Use a low privilege test account for every restricted feature.
Exercise role transitions
Permissions change when a user leaves a workspace, loses an administrator role, or accepts an invitation. A session issued before that change may still exist. Check what happens to subsequent actions using that session, and agree whether the product requires immediate revocation or a documented delay.
- Check a removed member against the old workspace's test record.
- Confirm the remaining administrator still has legitimate access.
- Record the session age and role change time in the evidence.
Turn the matrix into regression coverage
Store allowed and denied cases beside the feature tests. When a new export endpoint appears, add its permission row before release. A compact, maintained matrix is more useful than a large checklist that assumes every application has the same roles.
Reference: OWASP Authorization Testing Automation Cheat Sheet.
Assessment limits
The tester cannot decide intended access rights from response behavior alone. Ambiguous sharing, support access, and delegated service permissions require product-owner input. One denied route does not establish that every route applies the policy.
Frequently asked questions
Is hiding an admin page an access control fix?
The protected operation needs a server-side permission check. Hiding the page may improve the interface, but direct API calls must enforce the same policy.
Should denied requests always return 403?
Some applications use 404 to avoid revealing a protected resource. The assessment should verify that data and state are protected, then document the chosen error behavior.
What is a useful access control test fixture?
Use a small workspace with separate roles, known records, and a written sharing policy. This lets you identify the exact permission failure without touching unrelated customer data.
Primary sources and further reading
These guides combine published security guidance with practical assessment planning. Adapt checks to the owner's policy, environment, and authorized scope.