The IDOR vulnerability we found on day three of a recent web application penetration test should not have existed in 2026. The endpoint accepted an integer customer ID in the URL, performed no authorization check whatsoever, and returned the full account record — including billing history, internal notes, and exported document links — to any authenticated user who incremented the value. By the time we finished mapping the blast radius, we had read access to 4.2 GB of customer data belonging to other tenants. The development team was experienced. The codebase was modern. The CI pipeline ran static analysis on every commit. None of it caught the most basic class of authorization flaw in the OWASP API Security Top 10.
Insecure Direct Object Reference — IDOR — is one of those vulnerabilities that experienced engineers think they have eliminated. The reality is the opposite. The OWASP API Security Top 10 has placed broken object-level authorization at the top of the list for two consecutive editions. The Verizon Data Breach Investigations Report continues to flag web application attacks as a leading initial-access vector. And every senior penetration tester we know would tell you, off the record, that IDOR is the single most common high-severity finding they ship in any given quarter.
This is a field-notes post, written for product engineers, security leaders, and CTOs who want to understand what an IDOR vulnerability actually looks like when a senior tester finds one in the wild. We will walk through three engagements, the patterns that connect them, and the discipline that prevents this class of flaw from reaching production.
Why IDOR Vulnerability Findings Keep Surfacing in 2026
The structural reason IDOR persists is simple. Authorization is not a single check; it is a discipline that must be applied at every endpoint, on every object, for every actor, on every request. Modern frameworks make authentication trivial — a developer drops in a middleware and the user is identified. Authorization, by contrast, is a per-resource decision that the framework cannot make for you. When teams move fast, the authentication middleware ships and the authorization check is deferred to a follow-up ticket that never gets prioritized. By the time the application has fifty endpoints, the gaps are everywhere.
“Every IDOR finding I have ever shipped started the same way: someone assumed that because the user was logged in, they were also authorized. Authentication is who you are. Authorization is what you can touch. The two are not the same and most codebases pretend they are.”
Senior application penetration tester, iSECTECH engagement notes
Three IDOR Engagements That Defined Our Field Notes
Engagement One: The B2B SaaS Whose Document API Returned 4.2 GB of Cross-Tenant Data
The engagement that anchors this post involved a B2B SaaS platform serving 1,800 enterprise tenants. The document export endpoint accepted a numeric document ID. The application checked that the requesting user was authenticated. It did not check that the document belonged to the user’s tenant. We wrote a short script that walked the ID space, captured response sizes, and within ninety minutes had a sampling of documents from every major customer on the platform. The remediation took three days; the disclosure conversation with the largest customers took three weeks. The CTO’s words, after the readout, were: “We thought our framework handled this. It does not handle this.”
Engagement Two: The Healthcare Portal Whose Patient Record IDs Were Sequential UUIDs
The second engagement involved a healthcare patient portal that had — wisely — moved away from numeric IDs to UUIDs. The team believed this made enumeration impossible. What they had not realized was that their UUID generator was producing version-1 UUIDs, which embed timestamp and MAC-address data and are partially predictable. Combined with an IDOR flaw on the appointment-history endpoint, we were able to retrieve appointment metadata for a non-trivial sample of patient records. The OWASP API Top 10 explicitly calls out this anti-pattern: random-looking identifiers do not substitute for an authorization check. The remediation involved both a switch to version-4 UUIDs and — more importantly — a tenant-scoped authorization layer applied uniformly across the API.
Engagement Three: The Marketplace Whose Admin Endpoint Trusted a Client-Side Role Header
The third engagement is one we still cite in training. A two-sided marketplace used a custom X-User-Role header to indicate whether a request came from a buyer, seller, or administrator. The header was set client-side. The backend trusted it. By changing the header value to admin, we gained access to administrative endpoints that listed every transaction on the platform, including PII for both sides of every trade. The flaw is technically a broken-authorization issue rather than a textbook IDOR, but the failure mode is identical: the application treated authorization as a trust signal rather than a server-enforced control. NIST’s secure-software guidance is unambiguous on this: never trust client-supplied authorization data.
The Five Authorization Patterns Senior Testers Probe First
Our authorization-test playbook starts with five probes. The first is horizontal IDOR — can user A access user B’s resources by changing an ID? The second is vertical IDOR — can a low-privileged user access an endpoint intended for an admin? The third is tenant-boundary testing — in multi-tenant systems, can users in tenant A read or modify data belonging to tenant B? The fourth is mass-assignment testing — can a user pass extra fields in a request body to escalate their own role or modify protected attributes? The fifth is flow-state testing — can a user skip an authorization step by jumping directly to a later URL in a multi-step workflow? Mandiant’s M-Trends and the OWASP API Top 10 both reinforce that these five patterns account for the majority of high-severity authorization findings.
“The teams that ship secure APIs treat authorization the way accountants treat double-entry bookkeeping. Every operation has two checks: who is the user, and is the user allowed to touch this specific record. Skip either one and you have an IDOR waiting to happen.”
iSECTECH application security review summary
What Good Authorization Looks Like in Code
The codebases that pass our IDOR-focused testing share a common architectural choice: authorization is enforced at the data-access layer, not the controller. When the application asks the database for an object, the query is automatically scoped by tenant ID, user ID, or role — it is structurally impossible to retrieve a record the requester is not authorized to see. Frameworks that support row-level security in the database, or middleware that enforces tenant isolation at the ORM layer, make this discipline easier to sustain. The teams that get IDOR wrong almost always have authorization logic scattered across controllers, with no single place where the rule can be reviewed.
“If your authorization logic lives in your controllers, you have already lost. It needs to live somewhere a junior engineer cannot accidentally bypass it.”
Sean Metcalf, security architect, public conference commentary
How Boards and Executives Should Read an IDOR Finding
An IDOR finding in a penetration test report is not a routine bug. It is, almost without exception, a regulatory disclosure question waiting to be asked. If the vulnerability allowed access to data belonging to other customers, the question is not whether to disclose; it is when and how. Forrester research consistently shows that the organizations that handle disclosure well are the ones that already have a legal, communications, and engineering plan rehearsed before they need it. If your most recent pentest report contains an IDOR or broken-authorization finding, the executive question is simple: what evidence do we have that the flaw was not exploited before we found it? CloudTrail, application logs, and API gateway analytics are the answer — if they exist.
The Connection to the Rest of Your Security Program
IDOR findings rarely live in isolation. The same teams that ship broken-authorization endpoints often run penetration testing as a once-a-year compliance exercise, which is exactly the failure mode we covered in our piece on why “we passed our last pentest” has become the most dangerous sentence in cybersecurity. They also tend to under-invest in internal security review — the same gap that produces the Active Directory weaknesses we walked through in our Kerberoasting field notes. And they almost always lack the board-level visibility we argued for in our analysis of the six cybersecurity metrics that belong on every board’s quarterly agenda.
What to Do This Week
If your application handles multi-tenant data, multi-user data, or any sensitive object accessed by ID, run the five probes this week. Pick three endpoints; have a senior engineer attempt to access another user’s data with a valid session token. If the answer is anything other than a clean 403, treat it as a P0 incident. Authoritative external references for this work include the OWASP API Security Top 10, the Verizon DBIR, and NIST secure software guidance.
Talk to a Senior Application Security Practitioner
If you suspect your application has an IDOR vulnerability you have not yet found, that suspicion is worth acting on. iSECTECH’s senior testers have shipped hundreds of authorization findings to engineering teams across regulated industries. We do not run tooling and call it a pentest; we hunt the way attackers hunt. Book a confidential application security review with our senior team and we will tell you what we found and what to do about it.
Continue Reading: Week 3 Field Notes
Our Week 3 briefs extend the application-and-identity perspective: supply chain attack reality — the 42-line npm library, why your phishing simulation click rate hides real-world failure, and why the forgotten privileged account is still the most expensive failure mode.