Research guide
How to Test Role-Based Access Control (RBAC)
RBAC bugs are quiet: the UI hides a button while the API still answers. This guide covers the permission matrix, probing every role-resource-action tuple, and the anti-patterns that leak access in production.
Build the permission matrix first
A permission matrix maps role, resource, and action to the expected outcome: viewer can read reports but gets a 403 on delete, org admin can invite members but only within their own team, and so on.
Start with the production-critical tuples: billing, admin actions, member management, and cross-tenant access. A short matrix of high-risk cases is worth more than a long theoretical one.
Probe the API, not just the UI
For every forbidden tuple, call the API directly as that role and assert the exact status code and error code, not just that something failed. For allowed tuples, assert the response and that the data is scoped correctly.
The most dangerous RBAC bug is the UI that hides the button while the endpoint still answers. UI-only tests give false confidence.
The anti-patterns that leak access
Test for the classics: IDOR, where user A reaches user B’s resource by swapping an ID; client-side route guards that a direct URL bypasses; a default role on signup that is too permissive; stale claims after a role change; and field-level permissions that leak through a PATCH.
Also check the silent 403: a denial that writes no audit log is a compliance gap even when the access is correctly blocked.
Seed roles the way production assigns them
Create fixture users per role through the same path production uses, so middleware and claims are exercised. A database-only insert that skips the role-assignment logic can hide the very bugs you are testing for.
Parameterize specs by role and clean up roles and policies after the run so tests do not poison each other.
Escalation tests
Vertical escalation: a low-privilege token hits a higher-privilege endpoint. Horizontal escalation: a user reaches another user’s resource at the same privilege level.
Vary the HTTP method too. Some endpoints are protected on GET but leak on PATCH, or honor method-override headers.
Keep the matrix in sync
As roles and permissions change, regenerate the matrix and re-run the probes. The matrix is the executable spec for access control, so it must match product intent.
Combine RBAC tests with the login and signup guides, since role assignment usually begins at signup and team setup.
Key takeaways
- A permission matrix turns RBAC testing into explicit assertions, not guesses.
- Probe the API directly and assert exact status codes and error codes.
- Seed roles the way production assigns them, or tests miss middleware failures.