Overview
Where authentication asks "who are you?", authorization (access control) asks "what are you allowed to do?" Broken access control is consistently one of the most common and serious web vulnerabilities. This lesson introduces access control.
Learning objectives
- Distinguish authentication from authorization.
- Describe common access-control models.
- Explain why access control must be enforced server-side on every request.
Core concept
Access control determines whether an authenticated identity may perform a given action on a given resource. It is distinct from authentication: you can be correctly logged in (authenticated) yet still must be authorized for each specific action. Common models:
- RBAC (role-based) — permissions attached to roles (admin, editor, user).
- ABAC (attribute-based) — decisions based on attributes (owner, department, time).
- Ownership-based — a user may act on resources they own.
How it works
Every sensitive action must be checked on the server, for each request, against the current identity's rights — never assumed from the UI or a prior check. The server asks: does this identity have permission for this action on this object? If not, it denies (typically 403). Access control fails when this check is missing, incomplete, or client-side — e.g. hiding a button but not protecting the endpoint, or checking a role in the frontend only. Because authorization spans every action, it must be applied consistently and by default deny.
Practical example
An app has admin and regular users. A regular user should not reach /admin/reports. Proper access control checks, on the server, that the requester's role is admin before serving it — returning 403 otherwise. A broken implementation merely omits the admin link from the regular user's menu but leaves the endpoint unprotected, so the user can navigate directly and gain admin data. The security decision belongs in the server-side check, not the menu.
Cybersecurity relevance
Broken access control ranks at the top of industry risk lists because it is widespread and high-impact — leading to unauthorized data access, privilege escalation, and account/data compromise. Its subtypes (covered next: horizontal/vertical privilege issues, object-level authorization) all stem from missing or flawed server-side checks. Testers systematically try actions and resources they should not be allowed; defenders enforce default-deny checks on every action and resource, server-side.
Common mistakes
- Confusing authentication with authorization — being logged in is not permission for every action.
- Enforcing access control only in the UI (hidden buttons) rather than on the server.
- Failing to check every request/action, allowing direct access to unprotected endpoints.
Key takeaways
- Authorization (access control) governs what an authenticated identity may do; it is distinct from authentication.
- Models include RBAC (roles), ABAC (attributes), and ownership-based; all must be enforced server-side, per request, default-deny.
- Broken access control is a top web risk; it arises from missing, incomplete, or client-side checks and underlies privilege and object-level flaws.
Check your understanding
- What is the difference between authentication and authorization?
- Why is hiding a feature in the UI insufficient for access control, and where must the check occur?