Broken access control and IDOR vulnerabilities
Broken access control, often called IDOR (insecure direct object reference), is the single most exploited class of web vulnerability today. It happens when an API route accepts a resource ID from the request and acts on it without checking that the requesting user owns the resource.
#What goes wrong
Imagine a route like DELETE /api/orders/[id]. The handler reads the id from the URL, looks up the order, and deletes it. The route checks that the user is logged in, but never checks that the order actually belongs to that user. Any logged-in account can delete any order by changing the number in the URL.
#Why it matters
IDOR has been behind some of the biggest breaches of the last few years, including major fintech and healthcare incidents. The damage compounds because the attacker is already authenticated, so logs look normal and rate limits often do not catch it. A single missing ownership check can expose every user's data.
#How Heimdall checks for this
Heimdall reads every API route and looks for patterns where a resource is fetched, updated, or deleted by an ID from params or body, but no comparison is made between the resource's owner field and the session's user ID. The AI step verifies the route is genuinely sensitive before flagging.
#How to fix it
Before the database operation, look up the resource and confirm its owner field matches the session's user ID. On mismatch, return a 403 (or a 404 if you want to avoid leaking the resource's existence). Doing the check after the operation is too late.
Frequently asked questions
Does using UUIDs instead of integers fix IDOR?
What about admin routes?
Should I return 403 or 404 on a mismatch?
Run this check on your own repo
Heimdall scans your GitHub repo for this and 16 other issues in under a minute.