BOLA is the most common API flaw... and the easiest to not realize you have

Changing a number in the URL and seeing someone else's order is the simplest security test that exists — and the one most frequently skipped, because the API "already has authentication."

Authentication answers "who are you." Authorization answers "what can you see." The confusion between the two is the source of the most recurring flaw in the OWASP API Security Top 10, Broken Object Level Authorization — BOLA —, and it survives because an API can have flawless authentication and still leak everything, because nobody checked the second question.

The example that fits in a log line

GET /pedidos/1234 returns the order of whoever is authenticated — provided the backend checks, on every call, whether order 1234 belongs to that user. The BOLA vulnerability happens when the endpoint checks "is there a valid token?" and stops there, without checking "does this token have ownership over this specific resource?". Changing 1234 to 1235 in the URL, with the same token, still valid and still yours, returns someone else's order. It doesn't require a sophisticated exploit — it just requires someone to try.

That is the reason BOLA appears at the top of OWASP's list year after year: the test that finds it is trivial to run and the fix is conceptually simple (checking object ownership, not just token validity), but the vulnerability hides well because everything "works" in the happy path — the authenticated user accessing their own data never reveals the problem.

Rate limiting is a separate layer, not a substitute

Even with object-level authorization correctly implemented, an API without rate limiting remains vulnerable to enumeration: sequentially trying thousands of IDs until finding an accessible one, or simply overloading an expensive endpoint. Rate limiting does not replace ownership checks — it reduces the damage of someone trying to brute-force what the ownership check should have prevented anyway. The two defenses solve different problems and neither covers the absence of the other.

Machine-to-machine authentication is not "slap an API key on it"

For calls between services, three common patterns carry very different levels of security. A static API key is the simplest and most fragile — a long-lived value that, once leaked (log, repository, exposed environment variable), remains valid until someone remembers to rotate it. OAuth2 client credentials already introduces a short-lived token and declared scope, reducing the window of use for a leaked credential. mTLS goes further: the caller's identity is the certificate itself, verified at the transport layer before any request is processed — the strongest pattern, at the cost of more operational complexity to manage and rotate certificates.

The choice among the three is not about which is "more modern" — it is about how much damage a credential leak would cause and for how long, multiplied by the operational complexity the team can actually sustain.

Authorization testing belongs in CI, not just in the annual pentest

The pattern that truly catches BOLA early is running, with every build, a suite that authenticates as User A and systematically tries to access User B's resources — not waiting for the annual pentest to discover that a new endpoint, added three sprints ago, never had this check. API security that relies solely on periodic external audits will always find the vulnerability months after it was introduced, not when the code that created it was merged.

What to take away from this

BOLA exists because authentication and authorization are different questions, and it is easy to implement the first well while completely forgetting the second — the symptom never appears in the happy path, only when someone, malicious or not, changes an ID in the URL. Rate limiting protects against abuse even when authorization is correct; neither replaces the other. And the cheapest defense is to continuously test object ownership in CI, rather than discovering the vulnerability a year after it existed in production.

Sources

OWASP API Security Top 10 (2023) — API1:2023 Broken Object Level Authorization (owasp.org) — BOLA as the list's #1 risk, attack mechanism, and why it is common in APIs.

OWASP API Security Top 10 (2023) — API4:2023 Unrestricted Resource Consumption (owasp.org) — separate risk regarding lack of rate limiting.

OAuth.net — Client Credentials Grant, RFC 6749 §4.4 (oauth.net) — standard flow for machine-to-machine authentication via OAuth2.

OWASP Cheat Sheet Series — Authorization Regression Testing (cheatsheetseries.owasp.org) — how to automate authorization testing in CI.

Next edition: RBAC in practice — permissions that scale without turning into chaos.