How does access control work (RBAC, least privilege)?

Question

Accepted Answer

**Access control** governs what authenticated users can do — through models like **RBAC** (Role-Based Access Control) and principles like **least privilege**. Proper access control is critical, since broken access control is OWASP's #1 vulnerability.

## Access control models

```text
RBAC (Role-Based Access Control) → assign users to ROLES; roles have PERMISSIONS:
  → user → role(s) (admin, editor, viewer) → permissions → access decisions
  → manageable, common; change a role's permissions, all its users update
ABAC (Attribute-Based) → decisions based on ATTRIBUTES (user, resource, context) → flexible,
  fine-grained (e.g. "editors can edit docs in their department during business hours")
ACLs → per-resource lists of who can do what
```

## The principle of least privilege

```text
LEAST PRIVILEGE → grant the MINIMUM access needed to do the job, nothing more:
  → limits the BLAST RADIUS if an account/component is compromised
  → applies to users, services, processes, database accounts, API keys, etc.
→ a foundational security principle (default to LESS access; grant more only as needed)
```

## Implementing access control securely

```text
⚠️ BROKEN ACCESS CONTROL is OWASP #1 — common and serious:
✓ ENFORCE authorization on the SERVER for EVERY protected action/resource (never trust
  the client; don't rely on hiding UI elements)
✓ Check the user is authorized for the SPECIFIC resource (prevent IDOR — accessing
  others' data by changing an ID)
✓ DENY by default; verify on each request; centralize authorization logic
✓ Test access control (a common gap — easy to miss authorization checks)
```

## Why it matters

Understanding access control is important because it **governs what users can do and is critical to security** — broken access control is OWASP's #1 vulnerability — so it's valuable, practically-critical security knowledge.

Access control determines what authenticated users are permitted to do, and getting it right is essential.

Understanding the **models** — **RBAC** (assigning users to roles that have permissions — manageable and common), **ABAC** (attribute-based decisions for flexible, fine-grained control), and ACLs (per-resource permission lists) — provides the frameworks for structuring permissions, with RBAC being the most common to understand.

Understanding the **principle of least privilege** — granting the **minimum access needed**, which **limits the blast radius if an account or component is compromised** — is a foundational security principle applying broadly (users, services, database accounts, API keys), and one of the most important security concepts.

Critically, understanding how to **implement access control securely** addresses the #1 vulnerability: **enforcing authorization on the server for every protected action** (never trusting the client or relying on hidden UI — a common mistake), **checking authorization for the specific resource** (preventing IDOR, where users access others' data by changing an ID — a frequent broken-access-control flaw), **denying by default**, verifying on each request, and **testing access control** (a common gap, since missing authorization checks are easy to overlook).

Since access control governs what users can do and broken access control is the top vulnerability (common and serious), and since understanding the models (RBAC), the least-privilege principle, and secure implementation (server-side enforcement, resource-specific checks, deny-by-default) is critical for security, understanding access control is valuable, practically-critical security knowledge — addressing the #1 security risk, fundamental to controlling what users can do, and essential for avoiding the broken-access-control flaws (like IDOR and missing authorization checks) that are among the most common and serious vulnerabilities.