RBAC is fine for coarse function access, such as who may call admin routes. For decisions about specific objects, tenants or relationships, ABAC or ReBAC fit better. OWASP's Authorization Cheat Sheet recommends preferring them over plain RBAC, and it adds principles that apply to all three.
The three models
RBAC, role based. Users get roles, roles get permissions. Simple to explain and audit. The OWASP cheat sheet notes it struggles with object level decisions, role explosion and multi-tenant or cross-organization access.
ABAC, attribute based. The decision uses attributes such as job role, time of day or device type. More flexible, and policies can be more complex to write and test.
ReBAC, relationship based. The decision uses the relationship between a user and a resource, such as only letting a post's creator edit it. Natural for sharing, ownership and teams.
Comparison
- Admin versus regular user functions: RBAC: Good; ABAC: Good; ReBAC: Possible
- Only the owner can edit this record: RBAC: Awkward; ABAC: Good; ReBAC: Good
- Tenant isolation: RBAC: Needs many roles; ABAC: Good with a tenant attribute; ReBAC: Good
- Sharing a document with named people: RBAC: Awkward; ABAC: Possible; ReBAC: Good
- Context such as device or time: RBAC: Poor; ABAC: Good; ReBAC: Poor
Many systems end up with RBAC for function access and ReBAC or ABAC for objects.
Principles that apply either way
From the OWASP Authorization Cheat Sheet:
- Deny by default. Every request gets a permit or deny decision, and each grant should be justifiable.
- Least privilege. Minimum access for the role, reviewed after deployment to catch privilege creep.
- Validate permissions on every request. Prefer global filters or middleware over per-method checks that someone can forget.
- Enforce on static resources. Files and cloud storage need policies matching data sensitivity.
- Test authorization logic. Unit and integration tests should confirm deny by default and correct policy outcomes.
OWASP's BFLA guidance agrees: use one consistent authorization module that every business function calls, and deny all access by default.
How the models map to API flaws
- BOLA, accessing someone else's object: needs object level logic, which RBAC alone does not give. See the BOLA guide.
- BFLA, reaching admin functions: needs a role or group check on each function.
- Property level: needs field level decisions. See API3 explained.
How to pick
- List the questions your API must answer: who may call, who may touch this record, who may set this field.
- Use roles for the first, a relationship or attribute rule for the second.
- Put the decision in one place, as middleware or a policy service.
- Write tests per rule, including the deny cases.
Quick check
Is RBAC wrong?
No. It works for coarse function access. It becomes hard to manage when you use it for object level and multi-tenant decisions.
Do tests replace a security review?
No. OWASP says tests catch common issues but do not replace dedicated security testing or penetration testing.
Safeguard's policies, gates and compliance evidence automation can help you document and enforce such controls, and the free scan at gold.safeguard.sh/scan covers dependencies.
Sources
- OWASP Authorization Cheat Sheet
- OWASP API5:2023 Broken Function Level Authorization
- OWASP API1:2023 Broken Object Level Authorization
Last reviewed: 19 October 2026.
