Good web authorization starts from denial. Every request is refused unless a rule allows it, each user gets the least access their job needs, and the check runs on every request, not just the common ones. This checklist condenses the OWASP Authorization Cheat Sheet into things you can verify.
1. Deny by default
The cheat sheet says an application should always decide whether to permit or deny a request, and access should never be assumed. Configure controls explicitly instead of relying on framework defaults, and be able to justify each permission you grant.
Check: add a new endpoint without any rule. Does it return a refusal? If it returns data, your default is allow.
2. Least privilege
Users get only the minimum access their role requires. Define trust boundaries at design time and review permissions after launch to catch privilege creep.
Check: pick a user from the support team and one from sales. List what each can reach. Is anything there that they do not need?
3. Validate permissions on every request
OWASP's wording is that validating permissions correctly on just the majority of requests is insufficient. That includes AJAX calls, server-side code and other sources. Use application-wide mechanisms such as filters or middleware rather than per-method checks that someone can forget.
Check: list all routes and mark which pass through the central check. Any route outside it needs a reason.
4. Check the object, not only the role
A role says what kind of user someone is. It does not say whether this user may open this record. The cheat sheet prefers attribute-based (ABAC) and relationship-based (ReBAC) access control over role-based (RBAC) for most application development, because RBAC decisions depend only on assigned roles, which makes fine-grained, object-level and multi-tenant rules hard to express as roles multiply.
Check: log in as user A, copy the ID of user B's record, and request it. The answer should be a refusal.
5. Include static resources
Static files can be sensitive too. The guidance is to include static resources in access control policies and to secure cloud storage with the vendor's configuration tools.
Check: can you fetch an uploaded invoice from a direct link while logged out?
6. Test denial
Write unit and integration tests that confirm access is denied by default, that the app fails safely when a check fails, and that attribute policies are enforced. The cheat sheet notes automated tests catch common flaws but do not replace dedicated security testing or penetration testing.
Check: do you have a test that expects a refusal, not just a test that expects success?
Common mistakes
- Hiding a button and calling it access control.
- Checking authorization in the controller but not in the background job that does the same work.
- Trusting a role or ID sent from the client. See the mobile angle in why client-side checks must be repeated on the server.
- Letting every service account act as an administrator.
Where Safeguard fits
Authorization logic is your code, and a scanner will not know your rules. Safeguard's policies, gates and guardrails apply to your build and supply chain, and compliance and evidence automation can help you collect proof of reviews. You can scan a project for free.
Quick check
Is RBAC wrong?
No. The cheat sheet recommends preferring ABAC and ReBAC for most application development because roles alone struggle with object-level and multi-tenant rules. RBAC can still be a layer.
Where should the check live?
In an application-wide mechanism such as middleware, so no route can skip it.
Sources
Last reviewed: 19 October 2026.
