API Security Audit: What We Actually Test For

An API doesn't have a login page, a visible form, or anything a non-technical person would recognize as "the app." It's just endpoints, waiting for requests. That makes it easy to forget it's also the part of your system with the most direct line to your database — and the part automated scanners are worst at actually testing.

Here's what a real API security audit checks, and why most of the categories that matter need a person deliberately trying to break something, not a tool running a signature match.

Broken Object-Level Authorization (BOLA)

The single most common API vulnerability, and the API-specific cousin of the broken access control bug that shows up everywhere else. An endpoint like GET /api/users/482/orders returns user 482's orders based on nothing but the number in the URL — no check that the authenticated caller is actually user 482, or has any right to see their data.

This is a logic error, not a technical flaw a scanner recognizes. The request is perfectly well-formed. Nothing about it looks malicious. Finding it requires a tester logged in as one account, deliberately requesting another account's resource ID, and checking whether the server actually stops them.

Broken authentication

Weak token expiry, JWTs that don't actually verify their signature server-side, session tokens that don't invalidate on logout, or password-reset flows that leak whether an email exists in the system. Individually these look minor. Chained together, they're usually how an attacker goes from "no access" to "full account takeover" without ever guessing a password.

Mass assignment

An update endpoint that accepts a JSON body and writes every field in it straight to the database — including fields the frontend never intended to expose, like role or isAdmin. If a request that was only supposed to update a display name can also flip isAdmin: true because the backend never checked which fields were actually allowed, that's mass assignment, and it's a direct path to privilege escalation.

Excessive data exposure

An endpoint that returns the entire user object — including password hashes, internal notes, or other accounts' data buried in a nested field — because it was faster to build than filtering the response to only what the frontend actually displays. The frontend not rendering a field is not the same as an attacker not being able to read it directly from the response.

GraphQL-specific issues

If you're running GraphQL, introspection is usually left enabled in production, which hands an attacker your entire schema — every type, every field, every mutation — without them needing to guess anything. We also test for deeply nested queries used as a denial-of-service vector, and check that field-level authorization actually exists (a GraphQL API can accidentally expose a sensitive field through one query path while correctly protecting it through another).

Rate-limit and abuse testing

Login endpoints, OTP verification, and search/lookup endpoints without rate limits are open invitations to credential stuffing, OTP brute-forcing, and data scraping at scale. We test whether limits exist, whether they apply per-account and per-IP (not just one or the other), and whether they can be bypassed by rotating headers or IPs.

Why this needs manual testing, specifically

Every category above is a logic or business-rule problem, not a known-signature vulnerability a scanner pattern-matches against. A scanner can tell you a header is missing. It cannot tell you that endpoint A correctly checks authorization while endpoint B — doing functionally the same thing with a different URL — forgot to. That comparison requires a person who's read your actual API surface and is thinking like an attacker who already has a valid account and wants someone else's data.

Every finding from our audits ships with a working Postman or curl reproduction, so your engineering team can verify, fix, and retest without needing us in the loop for every iteration — and we cover REST, GraphQL, and WebSocket surfaces, since most modern applications run more than one of the three.

If you're shipping an API and have never had it specifically audited — as opposed to your web app more broadly — tell us about your setup and we'll scope what an audit of your actual surface looks like.