Skip to main content
Web Application Vulnerabilities
CHAPTER 08

Access Control and Authorization

Updated: May 15, 2026
25 min read

# 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. 1. Alice logs in. Her account ID is 105. She sees her statement.
  1. 2. Alice is curious. She changes the URL to account_id=106 and presses Enter.
  1. 3. The Flaw: The application queries the database for account 106 and returns the statement.
The application authenticated Alice, but it failed to *authorize* whether Alice actually owned account 106 before returning the data.

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:

php
1234567891011121314151617181920212223242526
session_start();

// 1. Enforce Authentication (Are they logged in?)
if (!isset($_SESSION['user_id'])) {
    die(header("Location: login.php"));
}

// 2. Enforce Vertical Authorization (Are they an Admin?)
// Let's assume we want to protect an 'Admin Settings' page
if ($_SESSION['role'] !== 'admin') {
    // Log the suspicious attempt for security monitoring
    error_log("User {$_SESSION['user_id']} attempted unauthorized admin access.");
    // Deny access
    http_response_code(403);
    die("Error 403: You do not have permission to view this page.");
}

// 3. Enforce Horizontal Authorization (Do they own the data?)
$requested_document_id = $_GET['doc_id'];
// Query the database to check ownership: SELECT owner_id FROM documents WHERE id = ?
if ($document_owner_id !== $_SESSION['user_id'] && $_SESSION['role'] !== 'admin') {
    http_response_code(403);
    die("Error 403: You cannot view another user's document.");
}

// If all checks pass, show the document.

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 the user_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.
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. 1. Define the Principle of Least Privilege (PoLP) and explain why it is a fundamental concept in secure architecture.
  1. 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.

14. Summary

In Chapter 8, we addressed the most critical logical flaw in modern applications: Broken Access Control. We established that Authentication (proving identity) is meaningless without rigorous Authorization (enforcing permissions). We analyzed how attackers exploit Insecure Direct Object References (IDOR) to escalate privileges horizontally and vertically. Finally, we defined the ultimate defense: enforcing Role-Based Access Control and strict ownership validation on the backend server for every single request, adhering to the principle of "Default Deny."

15. Next Chapter Recommendation

We have secured the web application interface. But modern web apps are powered by complex backend data pipelines. How do we secure the invisible plumbing? Proceed to Chapter 9: Secure API Development.

Finish this Chapter

Save your progress on your learning path and prepare for coding interview challenges.

Discussion

Join the discussion

Log in or create a free account to participate.

Sort: ·