You've locked the front door. The user is authenticated. They have a valid session token. And yet, they just accessed another user's data.
This is an Insecure Direct Object Reference (IDOR) vulnerability, and it's one of the most common security flaws in modern web applications. Authentication confirms who someone is. But it doesn't confirm they have permission to access what they're requesting. That requires a second layer: object-level authorisation.
A new guide from freeCodeCamp demonstrates how to prevent IDOR vulnerabilities in Next.js API routes - and the principles apply to any backend framework.
How IDOR Attacks Work
Here's the classic scenario. A user logs into your app and requests their profile data. The API call looks like this:
GET /api/user/profile?id=123
The server checks the session token, confirms the user is authenticated, and returns the data for user 123. But what if that user changes the request to:
GET /api/user/profile?id=124
If your API only checks authentication - not whether the logged-in user has permission to access that specific resource - it will return user 124's data. No password required. No elevated privileges. Just change the ID in the URL.
In simpler terms: imagine a hotel where your keycard opens your room. But if you walk down the hall and try another door with the same card, it opens that room too. The lock confirmed you're a guest. It didn't confirm which room you're supposed to access.
The Fix - Authorisation, Not Just Authentication
The solution is straightforward in concept but requires discipline in implementation. Every API route that accesses a resource must verify the requesting user has permission to access that specific resource.
In Next.js, that means adding an authorisation check after authentication:
First, authenticate the user - confirm their session is valid. Then, before returning data, check that the resource being requested belongs to that user. If the user ID in the session doesn't match the owner of the resource, return a 403 Forbidden error.
The freeCodeCamp guide walks through implementing this in Next.js API routes, but the pattern applies universally. Whether you're using Express, Django, Rails, or serverless functions, the principle is the same: match the user making the request to the resource being accessed.
Where IDOR Vulnerabilities Hide
The tricky part is remembering to apply this check consistently. IDOR vulnerabilities don't usually exist in high-profile endpoints like user login or account settings. They hide in the mundane routes - profile edits, document downloads, API keys, order history.
Anywhere a resource is identified by an ID in the URL or request body, you need authorisation logic. That includes:
GET requests that fetch data. PUT or PATCH requests that update records. DELETE requests that remove resources. Any endpoint where changing a parameter could expose another user's information.
The risk is highest in applications with complex permission models. If some users are admins, some are collaborators, and some are viewers, your authorisation logic needs to account for all those roles - not just confirm the user is logged in.
Why This Matters Now
IDOR vulnerabilities are consistently ranked in the OWASP Top 10 - the most critical web application security risks. They're also one of the most commonly exploited flaws in bug bounty programmes. Attackers look for them because they're easy to test and often lead to sensitive data exposure.
For developers building with frameworks like Next.js, the shift to API routes and serverless functions makes this even more relevant. Traditional MVC frameworks often had authorisation baked into their ORM or middleware. Modern frameworks give you more flexibility - but that means security is now your responsibility, not the framework's.
If you're building a SaaS product, a client portal, or any application where users have distinct data, this should be part of your security checklist from day one. It's not enough to authenticate users at the session level. Every route that touches user-specific data needs its own authorisation check.
The front door might be locked. But if every room inside is open, you don't have security - you just have the appearance of it.