The Security Audit That Found 23 Vulnerabilities in Our Production API

We’d been shipping software for four years without a formal security audit. Our internal security practices were reasonable — we didn’t store plain-text passwords, we used parameterized queries, we kept dependencies updated. We also had 23 vulnerabilities in production, ranging from informational to critical.

The Most Common Finding Category: Authorization Logic

Nine of our 23 findings were authorization-related. Not authentication — we had reasonable authentication. Authorization: checking not just that a user is logged in, but that they’re allowed to perform the specific action they’re requesting on the specific resource they’re targeting. Object-level authorization failures (accessing other users’ data by manipulating IDs) are consistently the most common API vulnerability in modern applications.

IDOR: The Finding That Embarrassed Us Most

We had three Insecure Direct Object Reference vulnerabilities — APIs where authenticated users could access other users’ data by changing a numeric ID in the request. These are straightforward to exploit and straightforward to prevent. We had them because we’d never thought to test for them. We now include IDOR tests in our standard API test suite for every resource endpoint.

The Process Change That Mattered Most

Beyond fixing the specific findings, the most valuable outcome was building security review into our development process. Security as a gate before deployment rather than a check after launch catches the category of issue that external audits find most commonly: authorization logic that’s correct for the happy path but broken for edge cases.