We Gave Attackers a Map and Called It Documentation
Here's something that should bother you: the same Swagger UI you exposed to help your frontend team integrate faster is also telling every attacker exactly what parameters your API accepts, what endpoints exist, and what the expected data types are. Your OpenAPI spec is attack surface documentation. You published it. You're proud of it. It has syntax highlighting.
The industry spent twenty years hardening perimeters — firewalls, DMZs, intrusion detection, the whole stack. Then we decided to publish detailed technical maps of our internal systems and call it "developer experience." I'm not against API documentation. I'm against forgetting that documentation is dual-use.
OWASP's 2023 API Security Top 10 is a damning list if you actually read it as an indictment rather than a checklist. Broken Object Level Authorization sits at number one, and it's been number one, and it will keep being number one because it's not a library vulnerability or a CVE you can patch. It's a design failure you have to think your way out of.
BOLA Is Not Complicated. That's Why It Keeps Winning.
Broken Object Level Authorization — BOLA, or IDOR if you're old school — is conceptually simple enough to explain to a non-technical executive in sixty seconds: your API returns data based on an ID in the request, and you're not checking whether the person making the request is allowed to see that ID's data. That's it. That's the whole thing.
The 2022 Optus breach in Australia is the case study that should be printed and taped to every API developer's monitor. An unauthenticated API endpoint — reportedly left exposed after a network migration — allowed sequential enumeration of customer records. Ten million records. Driver's license numbers, passport numbers, dates of birth. The attacker didn't use a zero-day. They incremented an integer. The sophistication level required was approximately that of a curious teenager with a browser and some patience.
What makes BOLA so persistent is that your unit tests probably pass. Your authentication middleware is working. Your JWT is valid. The access control failure happens one layer deeper, at the object level, because someone assumed that if a user is authenticated, their requests are implicitly authorized. These are not the same thing. Authentication tells you who someone is. Authorization tells you what they're allowed to do. Conflating them is how you end up explaining a breach to the Australian government.
The fix requires you to enforce ownership checks on every object retrieval. Every. Single. One. Not a middleware that runs generically — a deliberate check: does this authenticated identity have a relationship to this specific record? In practice, this means your queries should include the user's identity as a constraint, not just the requested ID. SELECT * FROM accounts WHERE id = :id AND owner_id = :user_id instead of SELECT * FROM accounts WHERE id = :id. The difference is one clause. The security delta is enormous.
Your API Is Leaking. You Just Haven't Noticed Yet.
REST APIs have a habit of being generous. Object serialization is easy, defensive serialization is annoying, so developers return the whole model and let the frontend pick what it needs. Except you're not just serving your frontend. You're serving everyone who can reach your endpoint.
Excessive data exposure — OWASP API3:2023 — is the pattern where your GET /users/{id} endpoint returns the full user object including password hash, internal flags, admin booleans, and whatever else lives in that database row, and you're relying on the mobile app to simply not display the sensitive fields. The mobile app does not protect you. Anyone with a proxy tool sees the raw response.
I've done API assessments where the authentication endpoint returned a is_admin: false field in the JSON response for a normal user. The developers knew the frontend never used it. They were wrong about what mattered. The question isn't whether your application uses the field — it's whether an attacker can modify the request to flip it, or whether that field leaks structural information about your authorization model. Both of those are problems.
GraphQL made this worse in an interesting way. REST at least gives you the illusion of resource-scoped endpoints. GraphQL gives users the ability to ask for exactly what they want — which sounds great until introspection is enabled in production and an attacker can query your entire schema, discover every type, every field, every relationship. Then they construct deeply nested queries that join across your entire data model in a single request, either to extract data or to crash your resolvers under query depth exhaustion.
Disabling introspection in production is table stakes. Query depth limits and query complexity analysis — libraries like graphql-depth-limit and graphql-validation-complexity exist for a reason — are what you actually need. But most GraphQL deployments I've encountered have neither, because the developer experience of disabling introspection is annoying and the attack scenarios feel theoretical until they aren't.
JWT Misconfiguration Is a Genre at This Point
The alg:none attack is almost a decade old. It's in every security training. It's been written about exhaustively. Libraries still ship without protecting against it by default, and developers still deploy those libraries without checking. The attack works like this: JWTs carry an alg header that tells the server which algorithm to use to verify the signature. If a server accepts alg:none, it skips signature verification entirely. An attacker strips the signature, sets the algorithm to none, modifies the payload to claim admin privileges, and walks in.
The more common JWT failure mode in 2024 isn't alg:none — it's weak secrets and missing expiry. I've seen production systems signing JWTs with the string secret. HS256 with a guessable or short secret is breakable offline with tools like hashcat against a captured token. If an attacker gets one JWT from your system, they can attempt to crack the signing key and then forge arbitrary tokens. There's no server-side state to invalidate. Your entire authentication layer is as strong as that secret string.
Then there's the expiry problem. Tokens without expiry — or tokens with expiry set to something like ten years — mean that a compromised token is compromised forever. Combine that with no token revocation mechanism (which stateless JWT architectures make deliberately awkward), and you have credentials that can't be invalidated after a breach. The ergonomic appeal of stateless auth has a real security cost that most teams don't account for until they need to respond to an incident and realize they can't force-logout anyone.
OAuth scope creep is adjacent to this. OAuth is supposed to enforce least privilege through scopes — an application requests only the permissions it needs. In practice, requesting broad scopes is easier than maintaining fine-grained scope lists, so you end up with third-party integrations holding read:everything write:everything indefinitely. When that integration is compromised, or when the vendor is acquired and their security posture changes, you've handed over a skeleton key.
Your API Gateway Is Not Your Security Team
Kong, AWS API Gateway, Apigee — these are real tools and they provide real value. Rate limiting, authentication offloading, TLS termination, basic request validation. If you're not using an API gateway of some kind, you're missing a layer of defense that's relatively cheap to add. But there's a dangerous tendency to treat the gateway as the security layer, full stop, and that's where things go wrong.
Rate limiting at the gateway level protects against volumetric abuse — someone hammering your login endpoint a thousand times a second will get throttled. What it doesn't protect against is business logic abuse at low request rates. An attacker running account enumeration at five requests per minute, across a distributed network of IP addresses, will pass right through your rate limiting while systematically mapping every valid email address in your system. This is a different threat model than a DDoS, and it requires a different response — behavioral analysis, CAPTCHA at inflection points, anomaly detection on per-session patterns.
Salt Security and Noname Security exist specifically because the API gateway doesn't see what the gateway sees as legitimate traffic. Their value proposition is API behavioral analysis — understanding what normal usage looks like and flagging deviations. Shadow API discovery is the other piece: APIs that aren't in your inventory, endpoints left over from deprecated API versions still running in production, internal APIs accidentally exposed to the internet because someone misconfigured a load balancer rule. You cannot secure what you don't know exists.
API versioning deserves a specific mention here because it's a security debt generator that almost nobody talks about explicitly. When you release /api/v2, what happens to /api/v1? In theory, it's deprecated and eventually shut down. In practice, it runs indefinitely because removing it might break something, some internal service still depends on it, and nobody wants to own the migration. So you have a production endpoint running old code, without the security fixes applied to v2, potentially with different authentication behavior, and it's receiving real traffic. The attack surface for APIs is additive across versions unless you're disciplined about sunset timelines, and almost nobody is.
The Uncomfortable Reality
The reason API security is in the state it's in isn't that developers are careless or that security teams are incompetent. It's that APIs moved faster than the security tooling and practices designed to protect them. We applied web application security models to a fundamentally different communication pattern — machine-to-machine, high-volume, stateless, with radically different authentication mechanisms — and were surprised when the controls didn't translate cleanly.
The API perimeter is real, it's porous, and the most dangerous attacks against it don't look like attacks. They look like legitimate, authenticated requests that happen to be asking for data they shouldn't have. That's a much harder problem than blocking a SQL injection string, and it requires you to think about authorization as a first-class design concern rather than something you'll add after the MVP ships.
You won't, though. Nobody does. And that's why BOLA is still number one.
