No exploit code, no hacking tools, just a browser address bar and a bit of curiosity. This is one of the most common, and most overlooked, ways business applications leak data.
A customer logs into an online billing portal to check their own invoice. Out of pure curiosity, they change the number at the end of the web address from 1042 to 1043. The page loads instantly, and it is not an error message. It is someone else’s invoice, full name, amount, payment history, all of it. No password was cracked. No malware was involved. They just changed a number.
This is called Insecure Direct Object Reference, IDOR for short, and it is one of the most common vulnerabilities found in business applications today. It requires no technical skill to exploit, which is exactly what makes it so dangerous. In 2019, this exact category of flaw let First American Financial Corporation accidentally expose over 800 million documents containing Social Security numbers and bank account details, simply because their application never checked whether the person asking for a document actually owned it.
This post breaks down what IDOR actually is, why it is so common, and what it looks like when it happens to a real business.
What IDOR Actually Means, in One Sentence
An application asks who you are when you log in, but never asks again whether you should be allowed to see the specific thing you are asking for. That is the entire vulnerability. The system correctly confirms your identity once, then trusts every request that follows without checking whether the record, file, or invoice you are requesting actually belongs to you.
Why It’s Called a Direct Object Reference
A direct object reference is simply an identifier, a customer ID, an invoice number, a file name, that the application uses to fetch something specific. These identifiers show up constantly in ordinary use, in a web address, a hidden form field, or an API request. The reference itself is not the problem. Plenty of secure systems use identifiers exactly like this. The vulnerability appears only when the system fails to verify that the person supplying that identifier is actually authorized to access what it points to.
The Simplest Version: One Number in a URL
The classic example is exactly the scenario at the top of this post, a URL like yourapp.com/invoice?id=1042. Change the number, and if the application does not separately verify ownership, it hands over whatever record matches that number, regardless of who is asking. When systems use simple, sequential numbers for these identifiers, which is extremely common, an attacker who knows their own ID is 1847 can reasonably guess that IDs 1 through 1846 belong to other real customers, and simply work through them one by one.
It Doesn’t Only Live in the URL
While the URL example is the easiest to picture, the same flaw shows up anywhere an application accepts an identifier from the user, hidden fields in a form, values inside an API request, even data tucked into request headers. Modern applications built around APIs, where a mobile app or another system requests specific pieces of data constantly, actually see this exact problem more often, not less. In that context it usually goes by a different name, Broken Object Level Authorization, but it is the identical underlying mistake.
Horizontal vs Vertical: Two Different Ways This Gets Exploited
Most IDOR cases fall into one of two patterns. The far more common one is horizontal, where an attacker accesses data belonging to another user at the same privilege level, one customer viewing another customer’s invoice, exactly like the opening example. The less common but more damaging version is vertical, where a regular user finds they can reach data or functions meant only for an administrator, simply because the same missing check applies there too.
Why This Is Rarely About Guessing the Next Number
It is tempting to think of IDOR as a simple sequential ID problem, and sometimes it is exactly that. But security researchers who specialize in finding these flaws consistently point out that the harder, more common cases hide deeper, buried inside authorization logic, object lifecycles, and assumptions about what a user should be able to do at a particular step in a process. A system might correctly block access most of the time, but miss one specific state, one specific endpoint, where the check was simply never added.
Why this matters
IDOR does not trip alarms the way other attacks do. There is no unusual traffic spike, no malware signature, no obvious error. It looks, to every normal monitoring tool, exactly like a legitimate, logged in user browsing their own account.
Why Automated Scanners Often Miss It
Most vulnerability scanning tools are good at finding flaws with a clear technical signature, malformed input causing a crash, a known outdated software version. IDOR does not announce itself that way. The application responds normally, returns a valid looking page, and gives no technical error at all. Catching it requires actually understanding whether the specific data returned should belong to the specific user who asked for it, a judgment call that tools built for pattern matching are simply not designed to make. This is a large part of why manual, human led penetration testing consistently finds IDOR issues that automated scans miss entirely.
Wondering whether your own applications have this exact gap?
Book a free security assessment and Ambsan’s team will test your access control logic properly, not just run a scan.
What a Real IDOR Breach Actually Looks Like
The First American Financial breach mentioned earlier is one of the largest documented examples, over 800 million sensitive financial documents exposed, discoverable simply by changing a number in a document URL, no login bypass, no stolen password required. More recently, security researchers have continued finding this same category of flaw in widely used plugins and platforms, underscoring that this is not a solved problem from years past. It is an ongoing, current risk that shows up in newly built software just as often as old systems.
How This Connects to the OWASP Top 10
IDOR is not treated as its own separate category anymore. In the current OWASP Top 10, it sits inside Broken Access Control, which holds the number one position, the single most common and most critical risk category across all the applications OWASP studied. If you read our recent breakdown of that full list, this post is effectively a close up look at the specific pattern responsible for a large share of what lands in that top category.
Why This Is So Common Despite Being So Simple to Explain
Developers are not careless. IDOR tends to slip through because checking permissions on every single request adds extra work, and it is easy to assume that if a user cannot see a link to something, they will never think to ask for it directly. That assumption fails constantly, because identifiers are rarely secret, they show up in URLs, browser history, shared links, and support tickets, all places a curious or malicious user might encounter one that was never meant for them.
What Proper Prevention Actually Looks Like
- Every single request for a specific object gets an authorization check, not just a login check, no exceptions for convenience
- That check happens on the server, never trusting a check performed only in the app or website the user sees
- Identifiers avoid simple, guessable, sequential patterns wherever practical
- Authorization logic gets tested against every state an object can be in, not just the obvious, default case
- APIs get the same scrutiny as customer facing pages, since this is where the same flaw increasingly hides
Checklist: Could This Be Happening in Your Application Right Now
- Do your invoice, order, or account URLs contain a visible, simple number you could try changing yourself
- Has anyone actually tested your APIs for this specific issue, not just your customer facing website
- Could a support agent or a curious employee access another customer’s data just by changing an ID in an internal tool
- Was your application’s authorization logic reviewed by a human, or only scanned by an automated tool
- Do you know, right now, whether every one of your application’s endpoints checks ownership, not just login status
How Ambsan Tests for This Specifically
Ambsan’s Application Security and VAPT services are built to catch exactly this category of flaw, not just run an automated scan and call it done. That means manually testing access control logic across an application’s actual user flows, checking APIs with the same rigor as customer facing pages, and verifying that authorization is enforced consistently, not just in the places that are easy to test.
This work ties directly into the broader application security testing we cover in our breakdown of the current OWASP Top 10, where Broken Access Control, the category IDOR lives inside, holds the number one spot for a reason.
Find out if this flaw exists in your application
Ambsan’s team manually tests your access control logic, the part automated scanners consistently miss.
Book a Free Security Assessment
Explore VAPT Services
Frequently Asked Questions
What does IDOR stand for?
IDOR stands for Insecure Direct Object Reference, an access control vulnerability where an application exposes an internal identifier, like a database ID or file name, without verifying whether the person requesting it is actually authorized to access it.
Is IDOR still part of the OWASP Top 10?
IDOR is no longer listed as its own standalone category, but it is explicitly covered within Broken Access Control, which holds the number one position in the current OWASP Top 10, reflecting how common and damaging this pattern remains.
Do you need to be a hacker to exploit an IDOR vulnerability?
No. In its simplest form, exploiting IDOR requires nothing more than changing a visible number or identifier in a web address or request, no specialized tools, malware, or technical skill required.
Can automated security scanners detect IDOR?
Automated scanners often struggle to detect IDOR because the application typically responds normally with no technical error. Identifying it requires understanding whether the returned data should actually belong to the requesting user, which usually requires manual testing.
What is the difference between horizontal and vertical IDOR?
Horizontal IDOR occurs when a user accesses data belonging to another user at the same privilege level, such as viewing another customer’s invoice. Vertical IDOR occurs when a regular user gains access to functions or data meant for a higher privilege level, such as an administrator.
What is BOLA, and how does it relate to IDOR?
BOLA, Broken Object Level Authorization, is the API specific term for the same underlying vulnerability as IDOR. It refers to APIs failing to verify that a caller is authorized to access a specific object they are requesting.
How common is IDOR in real applications?
IDOR is considered one of the most common web and API vulnerabilities found in professional security testing, and has been responsible for some of the largest data exposure incidents on record, including a breach affecting over 800 million documents in 2019.
How do you prevent IDOR vulnerabilities?
Prevention requires enforcing authorization checks on every request for a specific object, performed on the server rather than only in the visible application, and testing that logic across every state an object or user role can be in, not just the default case.
Does using random identifiers instead of sequential numbers fix IDOR?
It helps reduce the risk of an attacker guessing valid identifiers, but it does not fix the underlying vulnerability on its own. Without a proper authorization check, an attacker who obtains a valid identifier through any other means can still access data they should not be able to.
Final Thoughts
IDOR persists not because it is a sophisticated attack technique, but because it is the opposite, a simple, easy to overlook gap between checking who someone is and checking what they should be allowed to see. It requires no special tools to exploit and no technical background to stumble into by accident, which is exactly why it keeps showing up in real breaches, from a single curious customer to incidents affecting hundreds of millions of records.
The fix is not complicated either, checking ownership on every request, every time, without exception. The businesses that get hurt by this are almost never the ones who could not understand the concept. They are the ones who assumed it was already being done.
Related: The 10 Ways Your Web App Is Most Likely to Get Hacked in 2026
Related: Black Box vs White Box vs Grey Box Penetration Testing, Which One Does Your Business Actually Need
Related: Endpoint Security Compliance, What Businesses Need for ISO 27001, PCI DSS, and Cyber Insurance
Ready to see if this flaw exists in your app?
Book a free, no obligation consultation with Ambsan’s team and get a clear picture of your real application security posture.
Schedule a Consultation
See All Services
Ambsan Technologies is a Karachi based cybersecurity firm serving businesses across Pakistan and the United States, offering application security, VAPT, and managed IT services for SMEs and enterprises.