29. OWASP Top 10 Web Vulnerabilities
29.5 A01 Broken Access Control and IDOR
Broken access control is the #1 risk: a user can do or see things they should not. IDOR (Insecure Direct Object Reference) is the classic case – changing an ID in a URL to read someone else's data.
You see: https://app.com/invoice?id=1001 (your invoice)
You try: https://app.com/invoice?id=1002 (someone else's – and it shows!)
The server showed the record without checking that it belongs to you. This is horizontal escalation (Chapter 26) at the application level.
The fix – always check ownership and role on the server:
// after loading the record, confirm it belongs to the logged-in user
$stmt = $pdo->prepare("SELECT * FROM invoices WHERE id = ? AND user_id = ?");
$stmt->execute([$_GET['id'], $_SESSION['user_id']]);
if (!$row = $stmt->fetch()) { http_response_code(403); exit('Forbidden'); }
Never rely on hiding a button or a menu – enforce every permission on the server, for every request.
Ravindra Bagale's Tip
"Admin page cha link normal user la disat nahi, mhanun surakshit aahe" ha sarvat motha gairsamaj. Attacker link nako, thet URL type karto! Pratyek request la server var role ani ownership tapasa. Reels app madhe ek user dusryachi post delete karu shaknar nahi, he server var confirm kara.
Lab
In Juice Shop, log in and try to view another user's basket by changing the id in the request (Burp). In your reels app, add an ownership check to every action (view, edit, delete) and confirm one user cannot touch another's posts.