API Security in 2026: Why the Endpoint Nobody Documented Is the One That Leaks, How Broken Object Level Authorization Actually Works, and What to Fix First
- Internet Pros Team
- September 1, 2026
- Networking & Security
The uncomfortable thing about most API breaches is how boring they are. No zero day, no malware, no clever exploit chain. Somebody changed a number in a URL, the server answered helpfully, and a few hours later a script had walked through every customer record in the database. The request was perfectly valid, the traffic looked normal, and nothing in the logs stood out until somebody went looking.
Your Website Is Now a Thin Shell Around a Pile of APIs
A decade ago a web application rendered pages on the server and the browser displayed them. Today the page is a shell that loads and then makes dozens of API calls: one for the user profile, one for the cart, one for pricing, one for recommendations, one for the chat widget, several for analytics. Your mobile app hits the same endpoints. So does the partner integration, the internal admin tool, the reporting job and the automation nobody remembers building.
The result is that the majority of traffic reaching most businesses is no longer human beings clicking links. It is software talking to software. That shift moved the attack surface without moving the security budget. Firewalls, bot filters and page level access controls were designed for a world of documents and forms, and they largely evaluate the wrong things when the request is a JSON call carrying a bearer token.
There is a second shift on top of it. AI agents now consume APIs on behalf of users, which means more automated traffic, from more places, with credentials that were often issued in a hurry. Machine identities have quietly outnumbered human ones in most organisations, and each one is a key that can be stolen, over-scoped, or simply forgotten.
Most API breaches are not a failure of authentication. The attacker logged in legitimately. It is a failure of authorization, where the server confirmed who you are and then never asked whether this particular record was yours.
Broken Object Level Authorization, Explained Without the Jargon
This flaw sits at the top of the OWASP API Security Top 10 for a reason, and it is easier to understand than the name suggests. Imagine an endpoint that returns an invoice: GET /api/invoices/10432. You are logged in as a real customer with a valid session, so the request is authenticated. The server looks up invoice 10432 and returns it.
The bug is what the server did not do. It never checked that invoice 10432 belongs to you. Change the number to 10433 and you get somebody else. Write a ten line loop and you get everybody. The endpoint behaves exactly as designed on every single request, which is why automated scanners and traditional monitoring miss it. There is no error, no anomaly, no injection payload. Just a lot of successful responses.
The same pattern hides in every operation, not just reads. Deleting an object you do not own, updating an order that belongs to another account, or adding a user to a team you have no rights over are all the same missing check wearing different clothes. And it is worse in APIs than in old server rendered apps because APIs expose object identifiers directly by design, one per resource, all day long.
The Failures That Show Up Again and Again
| Weakness | What it looks like in practice | The fix |
|---|---|---|
| Broken object level authorization | Changing an ID in the request returns another customer record | Ownership check on every object, enforced centrally rather than per handler |
| Excessive data exposure | The endpoint returns the whole database row and the front end hides most of it | Explicit response schemas that list what may be sent, never the raw model |
| Mass assignment | Posting an extra field such as role or account_balance quietly updates it | Allowlist the fields a request may write; reject the rest |
| No rate limiting | Login, password reset and search endpoints answer thousands of times a minute | Per-identity and per-IP limits, tighter on authentication and expensive queries |
| Shadow and zombie endpoints | An old API version, a test route or a forgotten webhook still answering in production | Continuous discovery from live traffic, then decommission with a sunset date |
| Business logic abuse | Valid calls in an invalid sequence: applying a discount twice, refunding before payment clears | Enforce state transitions server side, never trust client-supplied workflow order |
You Cannot Protect an Endpoint You Do Not Know Exists
Ask a development team how many APIs the company runs and you will usually get a number from documentation. Compare it to what is actually answering requests and the real figure is routinely higher, sometimes dramatically so. The gap is filled with endpoints created for a one-off integration, versions kept alive because a single partner never migrated, staging routes that quietly went live, and services built by teams that no longer exist.
These are the endpoints that leak, and not by coincidence. Documented APIs get reviewed, tested and gated. Undocumented ones inherit none of that. They often sit on older code paths where the authorization checks that were added later never made it, and they rarely appear in the inventory a penetration test scopes.
The practical remedy is to build the inventory from live traffic instead of from documents. Whatever sits in front of your applications, whether a gateway, load balancer, CDN or reverse proxy, already sees every request. Aggregating those logs into a list of every hostname, path and method actually being served is the single highest value hour of API security work most organisations can do, because everything else depends on knowing the list.
A Practical Order of Operations for a Small Team
- Build the real inventory. Pull every distinct path and method from gateway or server logs for the last 30 days. Mark each one as owned, unknown, or should not exist.
- Test ownership on the top ten endpoints. Create two ordinary accounts and try to read and modify account B while logged in as account A. This finds more real risk than any scanner.
- Centralise the authorization check. If each route decides for itself whether the caller owns the object, one forgotten route is a breach. Enforce it in shared middleware or the data access layer.
- Rate limit authentication and search first. These are where credential stuffing and scraping land, and both are cheap to throttle.
- Trim your tokens. Inventory API keys and service credentials, scope each to the minimum it needs, set expiry dates, and rotate anything that has been valid since a previous employee configured it.
- Return only what the screen displays. Filtering in the front end is not filtering. The data was already sent.
- Log identity, not just status. Records that capture which identity touched which object make abnormal enumeration visible; response codes alone never will.
Why the Usual Tools Do Not Catch This
A web application firewall inspects requests for known malicious patterns, and a BOLA request contains none. It is a well formed call from an authenticated user for a resource that genuinely exists. Signature based defences have nothing to match on. Similarly, automated scanners are good at finding injection flaws and misconfiguration, but they cannot know that invoice 10432 should belong to a different customer, because that is business context no tool infers on its own.
What does work is behavioural: watching how many distinct object identifiers a single identity touches in a short window, and alerting when one account starts reading records in a pattern no human workflow would produce. That capability is now standard in dedicated API security tooling, and it can be approximated surprisingly well with the logs you already collect plus a scheduled query.
The Honest Summary
API security is less about buying a product and more about closing a gap between two things every team already believes it has: an accurate list of what it runs, and a consistent rule about who may touch what. Most organisations have neither, and the two failures compound, because the endpoints missing from the list are exactly the ones missing the rule.
None of the fixes above require a new platform or a large budget. They require a few hours of unglamorous inventory work, a habit of testing with two accounts instead of one, and a decision to enforce ownership checks in one place rather than in fifty. Regulators, insurers and enterprise customers are increasingly asking for evidence of exactly that. The businesses that get ahead of it will not be the ones with the most security tooling. They will be the ones that can answer, without guessing, what their APIs expose and to whom.
