What is authorization?
Authentication answers "who are you"; authorization answers "what are you allowed to do." Roles and permissions decide whether a given user can read, edit, or delete a given resource. It is enforced on the server, on every request, for every protected action.
Why it matters
Authorization bugs are among the most common and damaging — a user accessing another user's data, or performing an admin action they should not. Because the check must happen server-side on every action, and the UI only hides what it cannot truly protect, getting authorization right is core full-stack security.
What to learn
- Authentication versus authorization
- Role-based access control (RBAC)
- Resource ownership checks
- Enforcing on the server, every request
- Hiding UI as convenience, not security
- Attribute-based rules where roles are too coarse
- Centralizing authorization logic
Common pitfall
Enforcing permissions only by hiding buttons in the UI while leaving the endpoint open. An attacker calls the API directly and the action succeeds, because the only "check" was a hidden button. Every protected action must verify authorization on the server — including that the user owns the specific resource — regardless of what the client shows.
Resources
Primary (free):
- OWASP — Authorization cheat sheet · docs
- OWASP — Access control · docs
- Auth.js — Authorization · docs
Practice
Add role-based authorization: define a couple of roles, protect an action so only the right role can perform it, and add an ownership check so a user can only edit their own resource. Verify by calling the endpoint directly as the wrong user and confirming it is denied. Done when the server, not the UI, enforces access.
Outcomes
- Separate authentication from authorization.
- Implement role-based access and ownership checks.
- Enforce authorization on the server every request.
- Treat hidden UI as convenience, not protection.