IDOR: the bug that leaks your customers’ data.
Why Insecure Direct Object References remain the #1 vulnerability found in modern SaaS apps, why scanners miss them, and how to write authoritative access control tests.
7 min read
Insecure Direct Object References (IDOR) happen when an application uses user-supplied input to access objects directly without performing authorization checks. In B2B SaaS, this is the vulnerability that leaks tenant workspaces, customer PII, and financial records.
Why automated tools miss IDOR
To an automated security crawler, changing `org_id=10` to `org_id=11` and receiving a `200 OK` response looks completely normal. The scanner has no model of who owns what object. It requires dual-context differential testing — replaying user A's requests as user B — to detect unauthorized data exposure.
Defending with Row Level Security (RLS)
The most robust defense against IDOR is moving tenant isolation down into the database layer via PostgreSQL Row Level Security (RLS) or multi-tenant database adapters so that application developers cannot accidentally omit `where: { orgId }` clauses.
keep reading
Web & API Security · 7 min