How AI is applied across API Evangelist and APIs.io. Read my AI disclosure →
API Evangelist API Evangelist
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC

What is the biggest API security risk?

lock Security & Authentication Updated August 12, 2026

Short answer

The APIs you do not know you have, followed closely by broken object-level authorization on the ones you do. Both are inventory problems before they are code problems.

The unknown unknowns. The staging API that got a public DNS record and never came down. The v1 nobody retired because one partner still uses it. The internal service that got exposed through a gateway rule change nobody reviewed. The debug endpoint. The mobile backend that was never in the catalog because it was “not really an API.”

You cannot secure, patch, monitor, or rate limit what you do not know exists, and no amount of security tooling compensates for an incomplete inventory. This is why I keep insisting that awareness is the precondition for governance and for security alike. Discovery — of everything running, everything with a DNS name, everything a gateway routes to — is security work, even though it never gets budgeted as such.

Among the APIs you do know about, the persistent leader is broken object-level authorization: authentication works fine, the caller is who they say they are, and then they change an ID in the path and read somebody else’s data. It is common because the check has to happen per object on every operation, and it is easy for one operation out of a hundred to miss it.

Both problems are systematic rather than clever. They are found by inventory and by testing every operation for the authorization check, not by buying a product. That is exactly why they persist.

Go deeper in the guidance

This answer is distilled from the API Evangelist guidance catalog — the long-form treatment of each topic, with its own citations back into sixteen years of writing.

Read the original writing

The posts on apievangelist.com this answer is built on.