API Security: The Blind Spot Behind Every Integration

7 Min. read time

The frontend is locked down, the login is solid, the firewall is up. Then a mobile app calls an API that delivers every customer’s order-just by incrementing the ID in the request by one. No exploit tool, no zero-day, just a missing check. That’s exactly where the attack surface has shifted in recent years: to the APIs behind the visible apps. And they’re often less protected than what’s up front.

Key Takeaways

The attack surface has relocated. Instead of a single website, today there are dozens of APIs behind apps, integrations, and partner connections-each with its own data access.
BOLA tops the OWASP list. Broken Object Level Authorization-where incrementing a foreign ID is enough-is one of the most common API flaws and rarely appears in intentionally written code.
You only protect what you know. Shadow and zombie APIs from old releases are the silent problem. An API inventory is step one, not step five.
The countermeasures are unglamorous. Object-level authorization, rate-limiting, schema validation at the gateway. It’s about configuration and discipline-not an expensive appliance.

Why the Attack Surface Has Moved Behind the App

A decade ago, the website was the gateway. Today, it’s just the facade-APIs do the heavy lifting behind the scenes. The mobile app talks to an API, the partner portal pulls data through an API, the ERP syncs via an API, and the AI assistant someone just integrated? It calls an API too. Each of these connections is a door through which data flows in and out.

Close-up of color-highlighted code on a screen. — APIs are often coded quickly to serve an app, with security checks deferred for later. Photo: Godfrey Atima / Pexels

The uncomfortable truth? These doors are far less visible than the front entrance. A pentest might scrutinize the web app, but an API endpoint used only by a mobile app can easily slip through the cracks. I’ve lost count of how many times I’ve stumbled upon an API the team swore no longer existed.

BOLA and the OWASP List: Where It Specifically Fails

What is API Security? API security encompasses the measures that protect an interface from misuse: correct authentication, authorization at the object and function level, load limitation, and verification of the data passed. It differs from classical web security because in an API, every call directly hits the business logic without a protective surface in front of it.

The OWASP API Security Top 10 is the most useful map for vulnerabilities that actually occur in practice. At the top is BOLA, Broken Object Level Authorization. The server checks if someone is logged in, but not if the requested object also belongs to them. A call to /api/orders/1043 delivers their own order, a call to /api/orders/1044 delivers someone else’s. No tool needed, a counter suffices.

Right next to it are broken authentication, where tokens live too long or are checked too leniently, and unlimited resource consumption, where a single client with unbridled requests forces the interface to its knees. None of these gaps are exotic. They arise because an API was built quickly to serve an app, and security questions were postponed to later. This later rarely came in practice.

Classical Perimeter View	API Reality
Protects the visible web application	Dozens of endpoints, many of which are not documented anywhere
Attack via input fields and sessions	Attack via incremented IDs, token weaknesses, and load
A WAF covers a lot	Authorization must be located per object in the application

Shadow APIs: You Only Protect What You Know

The biggest problem is rarely the interface that everyone talks about, but the one that no one remembers. Shadow APIs arise when a team quickly builds an endpoint and never takes it into the official documentation. Zombie APIs are old versions that continued to run after a release because they didn’t hurt anyone. Both are unpatched, unchecked, and often without current access rules.

Therefore, API security does not start with a tool, but with a list. If you don’t know your endpoints, you can’t secure them, monitor them, or shut them down. This sounds trivial, but it’s the step that most people skip because it looks like drudgery. Without this drudgery, the rest remains cosmetic.

Five Steps That Carry the Bulk of the Load

The good news for medium-sized businesses: API security rarely requires a costly new appliance. It requires consistently doing a few things. These five steps carry the bulk of the load.

Maintain an inventory. Capture every endpoint, including old and unofficial ones. A gateway or a simple scan reveals what’s actually accessible.
Check authorization per object. With each call, not only check if someone is logged in, but also if they own the requested object. This is the direct answer to BOLA.
Centralize authentication at the gateway. Enforce token checks, expiration times, and scopes centrally, rather than rebuilding them in every application, which is error-prone.
Implement rate limiting. A limit per client makes rapid ID testing more difficult and catches overload from a single caller. The actual BOLA fix comes from object authorization in step two.
Validate inputs against the schema. Anything that doesn’t match the expected structure is rejected before it reaches the business logic.

None of this is new, and that’s the point. API gaps don’t arise from a lack of knowledge, but because the interface was built under time pressure and security was postponed. Setting this configuration as a standard once is cheaper than the first incident where someone has pulled the orders of the entire customer base.

The First Step Without a Security Team

If you don’t have a security team, don’t start with the most expensive tool, but with the most uncomfortable question: Which interfaces do we have, and who can access which data through them? The answer to this typically reveals more than any purchased scanner. An API gateway, which many cloud providers offer, centralizes authentication, rate limiting, and logging in one place and turns scattered doors into a controlled entrance.

The rest is attitude. An interface isn’t finished until someone has decided who can call it and what happens if someone does it too often. As long as this decision is missing, the API isn’t a product, but an open window that just hasn’t been found yet.

Frequently Asked Questions

What distinguishes API security from classical web security?

Classical web security protects a surface behind which the logic lies. An API has no surface; every call directly hits the logic. Therefore, a WAF isn’t enough; the actual control, especially object authorization, must reside in the application itself.

What is BOLA and why is it so widespread?

BOLA stands for Broken Object Level Authorization. The server checks if a user is logged in, but not if they own the requested object. If someone increments an ID in the request, they see foreign data. It’s widespread because the check is easily forgotten when an API is quickly built for an app.

Do I need an expensive API security tool?

Not at first. An API inventory, object authorization, a gateway for authentication and rate limiting, and schema validation cover the bulk. Specialized tools help with scaling and detecting shadow APIs, but aren’t a substitute for the basics.

What are shadow and zombie APIs?

Shadow APIs are endpoints that were built but never documented. Zombie APIs are old versions that continue to run after a release. Both evade monitoring and often have outdated access rules. They’re a main reason why a complete inventory is the first step.

Where should a medium-sized business without a security team start?

With an inventory: Which interfaces exist, and who can access which data through them? Then use an API gateway, which many cloud providers offer, to centralize authentication, rate limiting, and logging. This is cheaper and more effective than a purchased scanner without basics.