API Security: Closing the Gaps OWASP Keeps Warning About

APIs are where the perimeter went

For most organizations, the majority of traffic crossing the network edge is no longer a person clicking through a website. It is one machine talking to another over an API — a mobile app calling a backend, a partner integration pulling orders, a microservice fetching a customer record, a third-party SaaS syncing data. Gartner has for several years described API abuse as a leading vector for web application data breaches, and the reason is structural: every API endpoint is a documented, predictable door into your data, and there are now far more of them than anyone is tracking.

The old model put a firewall and a login page in front of a monolith. The modern model exposes hundreds or thousands of endpoints, many of them created by teams moving fast, many of them undocumented, and a meaningful share of them forgotten entirely. That is the shift that makes APIs the new attack surface. The controls that protected the front door do very little for a REST endpoint that returns a customer object to anyone holding a valid token.

Figure: every service-to-service edge is a reachable endpoint — the count grows faster than any inventory kept by hand.

What the OWASP API Top 10 is really telling you

The OWASP API Security Top 10 is worth reading not as ten separate bugs but as a small number of recurring themes. The categories that dominate real incidents cluster tightly.

• Broken object-level authorization (BOLA). The single most common and most damaging API flaw. The endpoint authenticates you correctly, then hands back the object you asked for without checking that the object is yours. Change the account number in the request path from your own to someone else's, and the server obligingly returns their data. It is trivial to find and trivial to exploit at scale by simply iterating IDs.
• Broken authentication. Weak or missing token validation, tokens that never expire, JSON Web Tokens accepted without verifying the signature, credentials or keys embedded in a mobile app that anyone can extract.
• Excessive data exposure and broken object property authorization. The API returns the full database object and trusts the client to display only the approved fields. The attacker reads the raw response and collects the internal IDs, password hashes, or flags the UI was hiding.
• Unrestricted resource consumption. No rate limiting, no pagination caps, no request size limits. This enables credential stuffing, data scraping, and cost or denial-of-service attacks that quietly run up your cloud bill.

Notice the pattern: most of the list is authorization, not exotic memory corruption. APIs fail because they authenticate the caller and then forget to ask whether that caller is allowed to touch this specific object or field. Fix authorization discipline and you have addressed the bulk of the risk.

You cannot protect what you cannot see

Every API program should start with inventory, because the endpoints that cause breaches are almost always the ones nobody knew were live. Three classes of unknown API are worth naming:

• Shadow APIs — endpoints stood up by a team outside the normal review process, never registered, never security-tested.
• Zombie APIs — old versions (a deprecated /v1 left running next to /v2) that still accept traffic and still reach production data, but no longer receive patches.
• Undocumented parameters — debug flags, admin query strings, and internal fields that were never meant to be reachable from the outside.

Building this inventory means combining sources: your API gateway logs, traffic mirroring at the edge, cloud provider logs, code repository scanning for route definitions, and external discovery. This is the same discipline as attack surface management applied to the API layer — enumerate what is actually exposed, not what the architecture diagram claims. Until the inventory exists and is refreshed continuously, every other control below is being applied to an unknown fraction of your real surface.

Authentication and authorization, done at the object

Getting identity right is necessary but not sufficient. The endpoint has to enforce authorization on the specific resource, every time.

1. Validate tokens properly. Verify the signature, the issuer, the audience, and the expiry on every request. Short-lived access tokens with refresh, not long-lived static keys. Never trust a token because it merely decodes.
2. Check object ownership on every call. Before returning object 4815, the server must confirm the authenticated principal is entitled to object 4815 — from server-side session state, not from an ID supplied in the request. Use unpredictable identifiers (UUIDs) so enumeration is harder, but never rely on unguessability as the control.
3. Enforce least privilege per endpoint. A read scope should not permit writes. A customer role should not reach admin routes. Deny by default and grant explicitly.
4. Centralize the logic. Authorization scattered across hundreds of handlers drifts. Enforce it in shared middleware or a policy layer so one team cannot silently ship an endpoint that skips the check.

Validate the schema, constrain the response

Two complementary controls close a large share of remaining findings. On the way in, validate every request against a strict schema: expected types, lengths, ranges, and allowed fields only. Reject anything that does not conform rather than coercing it. This blocks mass-assignment attacks, where a caller adds an extra field such as an "isAdmin" flag that the server blindly binds to the object.

On the way out, return only the fields the client needs. Do not serialize the whole database row and filter in the browser. Define explicit response shapes so internal fields never leave the server. Pair this with hard limits — pagination caps, maximum page sizes, request rate and payload ceilings — to shut down scraping and resource-exhaustion abuse. These practices are core to a mature application security program and belong in the API framework itself, not bolted on per endpoint.

Gateways and WAAP at the edge, with real testing behind them

A gateway or Web Application and API Protection (WAAP) platform gives you a consistent enforcement point: centralized authentication, rate limiting, schema enforcement, TLS termination, and logging for every endpoint that sits behind it. That consistency is the point — it is far easier to prove a control is applied everywhere when it lives at the edge than to audit it in every service.

A gateway is a control point, not a security program. It enforces the rules you give it and sees only the traffic routed through it; a shadow API that bypasses the gateway gets none of its protection. Back the platform with testing that reasons about business logic the way an attacker does. Automated scanners are weak at BOLA because they do not know which objects should belong to which user. Human penetration testing finds exactly these authorization flaws by manipulating IDs, replaying tokens, and probing the sequence of calls a workflow assumes. Fold API endpoints into the regular test scope and re-test after significant change, not once at launch.

A practical order of operations

If you are starting from a typical position — many APIs, partial documentation, uneven controls — sequence the work so early effort buys the most risk reduction:

1. Build and continuously refresh the API inventory. Retire zombie versions.
2. Route every endpoint through a gateway or WAAP so enforcement is consistent.
3. Fix object-level authorization first; it is the most exploited flaw.
4. Add strict request-schema validation and constrained response shapes.
5. Apply rate limits, pagination caps, and payload ceilings everywhere.
6. Test with humans, track findings to closure, and re-test after changes.

Closing

APIs became the primary attack surface because the business moved to them faster than security instrumentation followed. The OWASP API Top 10 keeps repeating the same lesson: the failures are overwhelmingly about authorization and visibility, not clever exploits. An inventory-first program, authorization enforced at the object, strict validation, consistent edge controls, and real testing together close the gaps the list keeps warning about.

If you want help discovering what your organization actually exposes and locking those endpoints down, our team runs attack surface management, application security, and penetration testing for organizations across the US. Contact us to scope your API attack surface.