API security incidents are rising. Most were never 'hacks'.

Read past the headlines of this year's API-related breaches and a pattern emerges that should be more embarrassing than frightening: almost none of them involved anything a security engineer would call an exploit. No broken cryptography, no zero-days. Instead: an endpoint that returned more fields than the app displayed. A sequential identifier that invited enumeration. A token that outlived the partnership it was issued for. An API that everyone had forgotten was still deployed.

The industry's new OWASP API Top 10 makes the same point in list form: the leading risks are authorization mistakes and inventory gaps, not cryptographic ones. Attackers are not breaking in. They are walking through doors nobody remembered were doors.

The unglamorous causes

• Unknown endpoints: you cannot secure what is not on any list, and every estate we assess has APIs that are not on any list.
• Object-level authorization, the discipline of checking not just "may this caller use this endpoint" but "may it see this record", skipped because it is tedious.
• Credentials without lifecycle: keys with no expiry, no owner, and no revocation path, waiting patiently in a repository.
• Responses that overshare, because filtering happens in the client, and the client is optional.

The state of the art in API security is, overwhelmingly, doing the boring things everywhere, all the time.

Why "boring" is the hard part

It is worth being honest about why these failures persist despite being well understood. It is not that teams do not know about object-level authorization or credential expiry. It is that these controls are individually tedious and collectively enormous, a small discipline to apply to one endpoint, multiplied by every endpoint in a sprawling estate, forever. The security is not intellectually hard; it is operationally relentless, and relentless is exactly what human diligence is worst at sustaining.

This is also why breaches cluster in the parts of the estate nobody is looking at. The flagship API that the security team reviews quarterly is rarely the problem. The problem is the service a contractor built and left, the version that was supposed to be retired, the internal endpoint that was never meant to be reachable but is. The boring controls were probably applied to the important APIs. They were not applied everywhere, and everywhere is where the attacker looks.

Everywhere is the hard part

Any team can do these things for one API. The breaches happen in the estate's long tail, the service built by a departed contractor, the version that was supposed to be retired. That is why the practical answer is infrastructural: a gateway everything actually passes through, an inventory generated from traffic rather than memory, credentials that expire by default. Discipline that depends on every team's diligence is called hope. Discipline built into the platform is called architecture.