Authorization and Access Control

# CHAPTER 8

Authorization and Access Control #

1. Introduction #

2. Learning Objectives #

• Clearly define Authorization logic.

• Understand and implement Role-Based Access Control (RBAC).

• Identify Broken Object Level Authorization (BOLA / IDOR) vulnerabilities.

• Write secure PHP logic to verify ownership before modifying resources.

• Apply the principle of "Least Privilege".

3. Beginner-Friendly Explanation #

• Authentication: The security guard checks your ID badge at the front door. You are verified as a student. You are allowed inside.

• Authorization: You walk down the hallway and try to open the door to the Principal's Office. The door is locked. Your student badge doesn't work here; you need an "Admin" badge. Furthermore, if you go to the locker room, your student badge only opens *your specific locker*, not the locker next to it.

Authorization in APIs is building the locks for the Principal's Office (Role validation) and building the locks for the individual lockers (Ownership validation).

4. Real-World Attack Scenarios #

• BOLA (Broken Object Level Authorization): A popular ridesharing app had an endpoint GET /api/receipts?receiptid=1001. A user logged in, viewed their own receipt, and noticed the ID in the URL. They changed the URL to ?receiptid=1002. Because the API failed to check if receipt 1002 *belonged* to the logged-in user, the API happily returned a stranger's ride history and credit card details.

• Privilege Escalation: A user creates an account. They intercept the POST request and add "role": "admin" to the JSON body. The API blindly saves the data. The standard user is now an administrator and deletes the database.

5. Access Control Models #

1. 1. RBAC (Role-Based Access Control): Users are assigned roles (e.g., User, Editor, Admin). Endpoints are restricted based on these roles.

1. 2. ABAC (Attribute-Based Access Control): More complex. Access is granted based on attributes (e.g., "Managers can only edit documents created in their specific department during business hours").

6. Vulnerable vs Secure Code Examples (BOLA/IDOR) #

Vulnerable PHP (BOLA Flaw):

<?php
// 1. Authenticate user (We know who they are)
$logged_in_user_id = $_SESSION[&#039;user_id']; 

// 2. Get the ID of the document they want to delete from the URL
$doc_id_to_delete = $_GET[&#039;document_id'];

// 3. VULNERABILITY: Blindly deleting the document without checking ownership!
$db->query("DELETE FROM documents WHERE id = $doc_id_to_delete");
echo "Document deleted.";
?>

Secure PHP (Ownership Validation):

<?php
$logged_in_user_id = $_SESSION[&#039;user_id'];
$doc_id_to_delete = $_GET[&#039;document_id'];

// SECURE: Enforce ownership in the SQL query itself!
$stmt = $db->prepare("DELETE FROM documents WHERE id = ? AND owner_id = ?");
$stmt->execute([$doc_id_to_delete, $logged_in_user_id]);

if ($stmt->rowCount() > 0) {
    echo "Document deleted.";
} else {
    // Return generic error (403 Forbidden or 404 Not Found)
    http_response_code(403);
    echo "You do not have permission to delete this document.";
}
?>

7. PHP Examples (Role-Based Access) #

<?php
// Function to run at the top of protected API routes
function require_admin() {
    $user_role = $_SESSION[&#039;role']; // Or extracted from JWT payload
    
    if ($user_role !== &#039;admin') {
        http_response_code(403);
        echo json_encode(["error" => "Forbidden. Admin access required."]);
        exit; // Stop execution immediately!
    }
}

// Apply to endpoint
require_admin();
$db->query("DROP TABLE users"); // Only runs if admin
?>

8. The Principle of Least Privilege #

• If an API key is used by a script to backup database files, that key should only have READ access, never DELETE access.

• If a user is a "Guest", they should not have access to endpoints that modify data.

9. Best Practices #

• Never Trust the Client: The frontend UI hiding the "Delete" button is an illusion. Hackers bypass the UI. Authorization MUST be enforced on the backend.

• Use UUIDs instead of Sequential IDs: If your API uses sequential IDs (/users/1, /users/2), it is trivial for a hacker to guess IDs and test for BOLA vulnerabilities. If you use UUIDs (/users/550e8400-e29b-41d4-a716-446655440000), they are impossible to guess, adding an extra layer of defense (though ownership checks are still mandatory).

• Centralize Authorization Logic: Don't scatter if ($user == owner) statements throughout hundreds of files. Create a centralized middleware or function (e.g., checkownership($resourceid, $userid)) to handle it uniformly.

17. Next Chapter Recommendation #