checklists
Authorization Testing Checklist.
Security & Permissions Test role-based access, object-level access and permission boundaries the QA way — including the critical UI-vs-API check and IDOR. What to verify and the evidence to collect.
When to use this checklist
- When testing role-based features, sharing, or multi-tenant access
- After permission or role changes, or new admin functionality
- Whenever an action is hidden in the UI but still has a backing API
- As part of a security regression before a release
Authorization decides what an authenticated user is allowed to do. The most common real-world bugs are broken access control: a user reaching another user's data, or an action hidden in the UI that the API still performs. This checklist covers role-based access, object-level access, the UI-vs-API check, removed-user access and tenant isolation — all with controlled test accounts and approved environments.
0/13
Role-based access
0/4Each role can do exactly what it should — no more.
Object-level access
0/4Changing an identifier must not expose someone else's object.
UI vs API authorization
0/1The most important authorization habit in QA.
Removed users & tenant isolation
0/3Access ends when it should, and tenants stay separate.
Evidence
0/1Safe, clear evidence for any access finding.
Common Bugs
User can access another user's object (IDOR)
Changing an id in the URL or API returns another user's data because the server does not check ownership. Always verify ownership server-side, per object.
Hidden button but the API still works
The UI hides an action for some roles, but the backing endpoint has no permission check, so a crafted request succeeds. Enforce authorization on the server, not in the UI.
Removed user still has access
A user removed from a team or project keeps access because permissions are cached or links never expire. Revoke access immediately and invalidate shared links.
Shared link does not expire
An expired or revoked share link still loads the resource. Enforce expiry and permission checks on every access, not only at creation.
Recommended Tools
Run the same request with different user and role tokens to confirm each gets the correct 200 / 403 / 404.
Capture the request behind a hidden UI action so you can replay it as a lower-privileged user.
// Related resources