API Security Reviews That Happen Too Late to Matter

Most API security work happens at the wrong stage: a review or a pen test scheduled shortly before launch, checking a nearly-finished API for the kinds of gaps that are actually decided by choices made when the API's authentication and authorization model was first sketched out. By the time that review happens, findings like "this endpoint doesn't check resource ownership, it only checks that the caller is authenticated" usually require redesigning the authorization layer, not patching a header.

"The caller is authenticated" and "the caller should be allowed to touch this record" are different questions. Most real API vulnerabilities come from an API that only ever asks the first one.

Why the pre-launch review catches too little, too late

A security review at the end can verify that authentication exists, that inputs are validated, that rate limiting is configured. What it can't undo is an authorization model that was never designed to check per-resource ownership in the first place - a common gap where an API correctly confirms who a caller is but never confirms whether that caller should be allowed to touch this specific resource. That's not a bug a scanner reliably finds; it requires someone to reason about the data model, and by review time the data model and every client already built against it are fixed.

A pre-launch review checks	It usually can't catch
Authentication exists on every route	Whether it also checks resource ownership
Inputs are validated and sanitized	Whether the authorization model was designed correctly
Rate limiting is configured	Whether it's applied consistently across every endpoint
Secrets aren't hardcoded	Whether tokens are scoped narrowly enough

The decisions that actually determine API security

A handful of choices, made when the API is first designed, do most of the real work:

• Whether authorization is checked per-resource, not just per-endpoint. "The caller is logged in" and "the caller is allowed to access this specific record" are different checks, and conflating them is one of the most common real-world API vulnerability classes.
• Whether the API defaults to denying access and requires an explicit grant, rather than defaulting to open and requiring an explicit restriction. The default matters most exactly when someone forgets to add a check.
• Whether rate limiting and input validation are part of the API framework's baseline, not something added endpoint-by-endpoint as an afterthought.
• Whether secrets and tokens are scoped narrowly (short-lived, least-privilege) from the start, rather than broad, long-lived credentials that get narrowed later, if ever.

Building it in instead of testing for it after

None of this requires a dedicated security team for most engineering organizations. It requires treating authorization design as part of API design, not a separate concern to check afterward - deciding, for every new endpoint, exactly which resource-level checks it needs before the first line of implementation is written, and defaulting new routes to deny-by-default rather than open-by-default.

Where teams overcorrect

If your last real API security finding was "we forgot to check that the caller actually owns this resource," the fix is in how authorization gets designed, not in when you test for it.