Access Control and Authorization
# CHAPTER 8
Access Control and Authorization
1. Introduction
Authentication proves *who* you are. Authorization determines *what you are allowed to do*. The failure to properly enforce authorization rules—known as Broken Access Control—regularly claims the #1 spot on the OWASP Top 10 list. It is the most common and devastating logic flaw in web applications. In this chapter, we will define the Principle of Least Privilege, explore the vulnerabilities of Insecure Direct Object References (IDOR), and understand how to properly architect Role-Based Access Control (RBAC).2. Learning Objectives
By the end of this chapter, you will be able to:- Clearly distinguish between Authentication and Authorization.
- Define the Principle of Least Privilege (PoLP).
- Understand the mechanics of an Insecure Direct Object Reference (IDOR) attack.
- Explain Privilege Escalation (Vertical vs. Horizontal).
- Architect a basic Role-Based Access Control (RBAC) model.
3. Beginner-Friendly Explanation
Imagine an office building with an electronic keycard system.- Authentication: You swipe your card at the front door. The system verifies you are a valid employee and lets you into the lobby.
- Broken Access Control: You walk up to the CEO's office. You shouldn't be allowed in, but the door has no lock. You walk in and read confidential files.
- Proper Authorization: You walk up to the CEO's office. You swipe your card. The system checks your "Role." It sees you are a "Junior Developer," not an "Executive," and denies you access, keeping the door locked.
Broken Access Control happens when developers forget to put locks on internal doors, assuming that just because someone is inside the building, they are trusted.
4. Privilege Escalation
When authorization fails, attackers elevate their permissions.-
Vertical Privilege Escalation: An ordinary user figures out how to access an Administrator-only page (e.g.,
website.com/admin_panel). They escalate *up* the hierarchy to gain god-mode control of the application.
- Horizontal Privilege Escalation (IDOR): An ordinary user (Alice) accesses the private data of another ordinary user (Bob). They don't gain admin rights, but they cross a horizontal boundary to steal data.
5. Insecure Direct Object Reference (IDOR)
IDOR is the most common form of Horizontal Privilege Escalation. Imagine a banking app where the URL looks like this:https://bank.com/view_statement?account_id=105
- 1. Alice logs in. Her account ID is 105. She sees her statement.
-
2.
Alice is curious. She changes the URL to
account_id=106and presses Enter.
- 3. The Flaw: The application queries the database for account 106 and returns the statement.
6. The Defense: Zero Trust and RBAC
Authorization cannot be an afterthought. It must be enforced on every single request. Role-Based Access Control (RBAC): Assign users to roles (e.g.,User, Manager, Admin). In your code, before executing a sensitive action, verify the user's role against the required permissions.
Defending against IDOR:
Never trust the URL parameter. If the URL requests account_id=106, the backend code must perform a check:
*"Does the currently logged-in user (from the secure session cookie) have ownership rights over account 106?"* If no, return a 403 Forbidden error.
7. Mini Project: Build Role-Based Dashboard Access
Let's conceptualize a secure authorization check in PHP.Secure Workflow Concept:
8. Real-World Scenarios
In 2018, the United States Postal Service (USPS) had a massive IDOR vulnerability in their "Informed Delivery" API. The service allows users to see digital scans of their upcoming mail. The API used sequential user IDs. A security researcher discovered that any logged-in user could manipulate the API request by changing theuser_id parameter to any other number. The API failed to authorize the request, allowing the researcher to view the private mail scans, email addresses, and home addresses of over 60 million American citizens.
9. Best Practices
- Fail Securely (Default Deny): When architecting an application, the default state for any resource should be "Access Denied." You must explicitly write code to grant access. If your code crashes or a validation check is bypassed, the system should fail into a secure, locked state, not an open one.
-
Use Unpredictable References: Instead of using sequential IDs (
user=105), use UUIDs (user=f47ac10b...). While UUIDs do not replace authorization checks, they make it computationally impossible for an attacker to randomly guess another user's ID, providing defense-in-depth against IDOR.
10. Legal and Ethical Notes
Exploiting an IDOR vulnerability, even by accidentally changing a URL parameter and viewing someone else's data, constitutes unauthorized access under computer fraud laws (like the CFAA in the US). Security researchers must act with extreme caution and immediately cease testing if they access data belonging to another user.11. Exercises
- 1. Define the Principle of Least Privilege (PoLP) and explain why it is a fundamental concept in secure architecture.
- 2. Explain the difference between Authentication and Authorization, providing a real-world analogy.
12. FAQs
Q: Can I hide the Admin button in the HTML using CSS to prevent users from accessing the admin panel? A: Absolutely not. This is "Security through Obscurity." A hacker can simply view the HTML source code, find the URL for the admin panel, and navigate to it directly. Authorization must *always* be enforced on the backend server, never just hidden on the frontend.13. Interview Questions
- Q: Describe the mechanics of an Insecure Direct Object Reference (IDOR) vulnerability. Provide a backend code architecture strategy to mitigate it permanently.
-
Q: A developer implements a security check by verifying that a user's hidden form field contains
<input type="hidden" name="role" value="user">. Explain the catastrophic flaw in this access control design.