API security: the surface that grows fastest and gets the least dedicated attention

Practically every new product feature today is born as an API before it ever becomes a screen. A mobile app, a partner integration, one microservice talking to another — all of it is API traffic, growing faster than any other exposure surface a company has. And in practice, it's the one that gets the least dedicated security attention relative to the volume it represents.

Part of the reason is historical: application security matured treating the web page as its unit of analysis. An API isn't a page — it's a data contract between systems, and the mistakes that cost the most there are rarely the same ones a web application firewall was built to catch.

Why a traditional WAF isn't enough on its own

A web application firewall was built to recognize known attack patterns — SQL injection, malicious scripts, a cataloged exploit signature. Most serious API incidents use none of that: they use a perfectly well-formed call, authenticated with a valid credential, requesting a resource the system shouldn't have handed to that specific user.

That's an authorization logic failure, not a recognizable malicious pattern — and it's exactly the kind of thing a signature-based tool simply can't see, because the call, in isolation, looks legitimate.

The failures that show up most in practice

Two categories concentrate most of the real risk: broken object-level authorization — when swapping an ID number in an API call's URL exposes another user's data, because the system checks that you're authenticated but never checks whether that authenticated user should see that specific record — and excessive data exposure, when the API returns the entire database object and leaves filtering up to the client app, which doesn't always filter correctly.

Neither requires a sophisticated exploit. Both just require someone systematically testing what happens when a parameter changes — which makes these failures both common and cheap to fix, once found.

Zombie APIs: the old version nobody turned off

Any company that's shipped more than one API version has old endpoints still responding, with outdated documentation, often without the same level of control as the current version. Nobody turns them off on purpose — there's simply no formal process for retiring an endpoint, so it stays active, forgotten, until someone discovers it still works.

It's the same discovery dynamic that showed up here this week with unapproved SaaS — a surface that grows by accumulation, with no reliable inventory, until someone outside the company finds it before the company does.

API discovery before any control

The question that should open any API security initiative isn't "which protection tool should we buy" — it's "how many endpoints actually exist, documented or not, and what does each one expose." API discovery tools today can map real production traffic and reveal endpoints that never entered any formal inventory — information that usually completely changes what gets prioritized for protection first.

That mapping is a prerequisite for any serious validation afterward — including continuous offensive validation, which can only test what it knows exists.

Where it weighs heaviest

Sectors where APIs are critical business surface — financial services, any company where the mobile app is the main channel — feel this risk first and most directly, because the API there isn't supporting infrastructure, it's the product itself. But no modern company is exempt: if there's an app, an integrated partner, or a microservice, there's API surface growing off the radar.

Every endpoint is a door, not a technical detail

Treating API as an engineering concern, separate from the security conversation, is the most expensive mistake in this category. UNIQ helps clients build the API discovery and control layer inside the Exposure & AppSec architecture, always starting with the inventory — before deciding what protection makes sense for each endpoint.