Insecure Direct Object References: The Bug Founders Underestimate

What you need to know

• IDOR vulnerabilities result from missing authorization checks, not from using sequential IDs. UUIDs reduce guessability but do not prevent the bug.
• Every API endpoint that accepts an object identifier must verify that the authenticated user has permission to access the referenced object. Authentication proves who you are. Authorization proves what you can access.
• IDOR is consistently one of the highest-severity findings in bug bounty programs and security audits because it often grants direct access to other customers' data.
• Row-level security at the database level provides a defense-in-depth layer against IDOR. Postgres RLS and equivalent features in other databases enforce authorization at the data layer, not just the API layer.
• Testing for IDOR requires two accounts and a willingness to try to access one account's resources from the other. This test should be part of every feature deployment.

The core argument

The reason IDOR appears so frequently in early-stage SaaS applications is that it looks like working code. The endpoint returns the right data, the authentication works, and the feature does what the user expects. The bug is in what happens when a different user makes the same request with a different ID. That scenario does not appear in the happy path test, which is the test most developers run. It takes deliberate adversarial thinking to catch it, and most product engineers are not thinking adversarially when they are focused on shipping features.

The pattern that introduces IDOR is straightforward: an endpoint receives an identifier in the URL or request body, queries the database for the object with that ID, and returns the result. The authentication middleware verifies that the request is authenticated. Nobody writes the authorization check that verifies the object belongs to the authenticated user. This is not negligence; it is a missing step in a process that did not include an authorization checklist. The fix is equally straightforward: every query that retrieves or modifies a user-owned resource should include the authenticated user's ID as a filter condition. WHERE id = $1 AND user_id = $2 instead of WHERE id = $1.

The multi-tenant case is where IDOR gets more complex and the consequences of getting it wrong are more severe. In a multi-tenant SaaS where each customer's data is stored with a tenant_id, an IDOR in a tenant-owned resource gives one customer access to another customer's data. This is the scenario that ends customer relationships and triggers regulatory notifications. The defense is layered: application-level authorization checks on every endpoint, row-level security policies in the database that enforce tenant isolation, and regular testing from a second tenant account. When I built the data isolation architecture for Velmora, a three-layer approach was the standard: middleware that sets the current tenant context, query filters that always include the tenant ID, and RLS policies that enforce isolation even if both upper layers miss a check.

Common mistakes

1. Assuming authentication implies authorization. Authentication verifies that a request comes from a known user. It says nothing about whether that user has permission to access the specific resource they are requesting. They are separate checks and both must be present.

1. Relying on UUIDs for security. UUIDs make ID enumeration harder but do not prevent authorization failures. Any system that relies on ID secrecy for security has a broken authorization model.

1. Not testing cross-user access during feature development. Most developers test that their feature works for themselves. Testing that the feature correctly rejects requests from a different user is a separate test that needs to be part of the review process.

1. Applying authorization checks inconsistently across the API. A codebase where some endpoints check ownership and others do not is a codebase with IDOR vulnerabilities. Authorization checks should be systematic, not case-by-case.

1. Not auditing bulk operations. Endpoints that accept lists of IDs, such as batch delete or bulk export, need authorization checks on every ID in the list, not just the first one. A bulk operation that authorizes the first ID and then processes the rest without checking is a high-severity IDOR.

Where to start

1. Audit every API endpoint that accepts an object ID. For each one, verify that the query includes a user or tenant ownership filter. A code search for your primary resource query patterns will surface the ones that are missing the ownership check.

1. Write a two-account IDOR test for each resource type. Create accounts A and B in your test environment. Log in as A, note the IDs of A's resources. Log in as B and try to access them. Add this test to your test suite to prevent regressions.

1. Enable row-level security for your primary data tables. In Postgres, RLS policies can enforce tenant or user ownership at the database level as a second layer of defense. This catches the cases where application code is incomplete.

Related reading

• OWASP Top 10 for SaaS Founders: What Actually Matters
• Multi-Tenant Architecture: Shared vs Isolated Data Models
• JWT vs Session Tokens: The Auth Decision That Affects Everything
• How to Sell to Enterprise Without a Full Compliance Stack