Authorization Models: RBAC and ABAC
Authentication proves who you are; authorization decides what you may do — and most serious breaches escalate through broken authorization, not broken login. Role-based access control grants permissions by role; attribute-based access control decides from attributes of the user, resource, and context. This topic gives you a working model for Meridian's permissions and the discipline that keeps a foothold from becoming full control.
The single most common serious web flaw, which you will exploit in Chapter 6, is simply a missing authorization check. Getting this layer right is what makes a stolen low-privilege account a nuisance rather than a catastrophe.
RBAC — Permissions via Roles
Users get roles — support, billing, admin — and roles carry permissions. It is simple, auditable, and scales to most organizations, which is why it is the right default. Its failure mode is role explosion: when every edge case spawns a new role, you end up with hundreds of near-duplicate roles nobody can audit, which is its own security risk.
ABAC — Decisions from Attributes
Attribute-based access control computes the decision from attributes and context: department equals finance, and time is business hours, and the device is managed. It is more expressive and dynamic than roles, which makes it well suited to fine-grained and conditional access — and harder to reason about and audit. Many real systems are RBAC with a few ABAC-style conditions layered on top.
Deny by Default and Complete Mediation
Every request is checked, the default answer is no, and there is no path that skips the check. The most common authorization bug is not a wrong rule but a missing one — an endpoint that simply forgot to ask whether this user may do this thing. Deny-by-default flips the risk: a new endpoint is locked until explicitly opened, rather than open until someone remembers to lock it.
Least Privilege in Practice
Standing broad privileges are the problem. Just-in-time elevation, scoped service accounts, and regular access reviews keep privilege from accreting silently the way temporary grants and forgotten roles always do. The goal is that on any given day, every identity holds only the access it is actively using — so a compromise reaches little and an audit is possible.
RBAC — roles map to permissions; simple, auditable, the right default for most organizations. Watch for role explosion.
ABAC — policies over attributes and context; expressive and dynamic, great for fine-grained and conditional access, but harder to audit and get right. Many systems are RBAC with a few ABAC conditions added.
- Checking authentication but not authorization on an endpoint — "you're logged in" silently becomes "you can do anything," the root of broken-access-control bugs.
- Defaulting to allow, so a forgotten check exposes a resource; the safe default is deny.
- Role explosion in RBAC — hundreds of near-duplicate roles nobody can audit, which is its own security risk.
- Standing broad privileges (permanent admin, wildcard service accounts) that turn any single compromise into total compromise.
- Scattering authorization logic across every endpoint, so one is inevitably forgotten.
- Enforce deny-by-default and check authorization on every request at a central, hard-to-bypass layer.
- Start with RBAC and add attribute or context conditions only where genuinely needed, to keep authorization auditable.
- Apply least privilege with just-in-time elevation and time-bound access instead of standing admin.
- Review access regularly and remove what is unused; entitlement creep is a slow-motion breach.
- Verify ownership and permission on the specific object, not just that the user is authenticated (Chapter 6).
Knowledge Check
Why do more breaches escalate through broken authorization than through broken authentication?
- Authorization checks are scattered and easy to omit on a single path
- Authentication systems are mathematically unbreakable
- Authorization always relies on much weaker cryptography than the login step does
- Users rarely bother logging in at all
What does "deny by default" change about a newly added endpoint?
- It stays locked until access is explicitly granted
- It automatically writes all of the authorization rules for you
- It removes the need to authenticate users
- It makes every endpoint public by default
What is the typical failure mode of RBAC as an organization grows?
- Role explosion — hundreds of near-duplicate roles that nobody can audit
- Roles become impossible to assign to any user
- RBAC stops supporting more than one permission per role
- Authentication breaks once too many roles exist
You got correct