Role-based access control groups permissions around stable responsibilities, then assigns users to those roles through governed workflows. Define resources and actions first, keep roles understandable, enforce every decision on the server, scope roles to tenant or organization boundaries, and use explicit exceptions or contextual checks when a role alone cannot express the rule.
Who this is for: Product teams and developers designing roles and permissions for multi-user applications they own and operate.
- Start with resources, actions, and business responsibility before naming roles or copying an organization chart.
- Authorize each server-side request using role, scope, object, action, and current account state.
- Separate role assignment from role use, review conflicts, and expire exceptional grants.
Model resources and actions
List protected resources such as projects, invoices, users, documents, settings, exports, and audit records. For each, identify actions including view, create, edit, approve, delete, administer, and grant access. Distinguish actions with different consequences rather than hiding them behind a broad manage permission.
Add scope explicitly. A project editor may edit only assigned projects, and an organization administrator may act only inside one tenant. Ownership, assignment, record state, and separation of duties can affect a decision. When these conditions matter, roles provide a baseline and policy logic supplies the remaining context.
Create comprehensible roles
Group permissions that support a recognizable job responsibility. Name the role by that responsibility, document who should receive it, and show its sensitive capabilities. Avoid creating a new role for every individual or combining unrelated authority merely because one current employee performs both tasks.
Design a low-privilege default and separate administrative roles. Consider conflicts such as requesting and approving the same payment or creating and auditing the same account. Role inheritance can reduce repetition, but deep hierarchies make effective authority difficult to explain. Keep composition shallow and test the final permission set.
Enforce authorization consistently
Place authorization in trusted server-side code at every request path. Interface hiding improves usability but does not enforce access. Central policy helpers can reduce inconsistent checks, provided they receive the current actor, tenant, resource, action, and relevant state. Default to denial when required context is missing.
Protect background jobs, bulk APIs, imports, exports, and administrative tools with the same model. Avoid accepting a tenant or role claim solely because the client sent it. Load trusted assignment data and validate object scope. Record important denials and privileged successes without exposing sensitive record content in logs.
Govern assignments and evolution
Define who may request, approve, assign, change, and remove each role. High-impact roles may need stronger authentication and independent approval. Notify users or owners of meaningful grants. Temporary duties should use expiring assignments rather than permanent role changes that someone must remember to undo.
Test a permission matrix with synthetic users across roles, tenants, object states, and denied actions in an owned environment. Confirm backups and rollback before a major policy migration. Review role definitions, assignments, conflicts, exceptions, audit evidence, and current OWASP authorization guidance quarterly and after organizational or product changes.
Design roles for an expense application
An organization-owned app needs employees to submit expenses, managers to approve their teams, and finance staff to pay approved items.
- Define expense, receipt, approval, payment, user, and audit resources with distinct actions and states.
- Create submitter, team approver, finance processor, and access administrator roles with tenant and team scope.
- Prevent users from approving their own expense and separate payment processing from role assignment.
- Enforce decisions server-side and test synthetic cross-team, self-approval, stale-role, and bulk-export cases.
- Document assignment approval, temporary coverage, protected audit logs, policy backups, rollback, and escalation.
RBAC design matrix
Build this matrix before implementing role checks or migrating assignments.
- Resource model: object, tenant boundary, states, owner, sensitivity, and available actions.
- Role definition: responsibility, included permissions, excluded permissions, scope, inheritance, and conflicts.
- Decision inputs: actor, role, tenant, object, action, state, relationship, and default-deny behavior.
- Assignment governance: requester, approver, administrator, authentication, notification, expiry, and removal.
- Evidence: server tests, denied paths, audit events, backup, rollback, exceptions, and quarterly review.
Common mistakes
- Using interface visibility as authorization and leaving the server endpoint broadly accessible.
- Creating an administrator role that combines business approval, data export, identity grants, and audit deletion.
- Testing one happy path per role while missing tenant scope, object ownership, state changes, and bulk routes.
Try one
A project manager should edit assigned projects but view all projects in the same department. Express and test that authorization rule.
A sound answer defines separate view and edit actions. View requires the manager role plus matching tenant and department; edit also requires an active assignment to the specific project. Server tests use synthetic users across departments, tenants, assignments, removed roles, archived projects, and bulk routes. The design defaults to denial, limits role administrators, protects audit logs and policy backups, and escalates unexpected cross-scope access.
Sources
- OWASP Authorization Cheat SheetOWASP principles for deny-by-default and server-side authorization checks.
- OWASP Threat Modeling Cheat SheetOWASP guidance for structured application threat modeling.