Broken Access Control / IDOR

What it is#

An Insecure Direct Object Reference happens when an application exposes an internal identifier, such as a numeric id, a filename or a UUID, and lets a request act on it without checking that the current user actually owns or may access the thing that id points to.

How it works#

// booking.php?id=182
$booking = $db->query("SELECT * FROM bookings WHERE id = ?", [$_GET['id']]);
render($booking);

Nothing here asks "does this booking belong to the signed-in user?" Any authenticated account can walk the id space and read (or, worse, modify) records that belong to someone else.

Real-world impact#

IDOR is one of the most commonly reported bug classes in bug bounty programs precisely because it needs no special tooling: increment a number and watch what comes back. Impact ranges from reading another user's private data to full account takeover when the referenced object is a password-reset token or a session identifier.

How to prevent it#

$booking = $db->query(
    "SELECT * FROM bookings WHERE id = ? AND user_id = ?",
    [$_GET['id'], $currentUser->id]
);
if (!$booking) { http_response_code(404); exit; }

Every object lookup must be scoped to the requester, not just the requested id: an ownership check, not just an existence check.