API security testing: what it covers, and what a scan sees from outside

Your app has an API whether you set out to build one or not. Every fetch the frontend makes, every /api/ route, every direct call to Supabase or Firebase from the browser is an endpoint a stranger can call too, with the same request your own page just sent. API security testing is how you find out what those endpoints do when the person calling them is not you.

The term covers a range, from a one-line curl of a public endpoint to a full authenticated assessment, and the pieces find genuinely different things. Being clear on which piece finds which problem is the difference between a check that reassures you and one that actually reduces your risk. Here is the map, and then the honest part about which slice you can see from outside without logging in.

What API security testing is actually looking for

Most API flaws fall into a few buckets, and the industry reference is the OWASP API Security Top 10. Its current edition (2023) puts the same risk at number one that the 2019 edition did, because it never stopped being the most common: broken object-level authorization, or BOLA (API1:2023). The rest of the list covers broken authentication, over-exposed data, missing rate limits, and misconfiguration.

BOLA is worth understanding because it is both the most common API bug and the easiest to trigger. An endpoint takes an object id, /api/orders/1002, and returns the object without checking that the caller is allowed to see that order. Change the number to 1003 and you read someone else's. No exploit, no payload, just a different id in a URL your own app already builds.

The methods, and what each one finds

Three approaches show up under the API security testing label, and they push on your API with increasing force.

Reading what the API volunteers. The lightest form: send the requests a normal client sends and look at what comes back. This finds the exposures that need no attack to surface, an endpoint that returns more fields than the UI shows, a response carrying a password hash or an internal id, a GraphQL endpoint with introspection left on that hands over your whole schema, a Swagger page documenting every route including the internal ones. It is entirely passive and it catches a surprising amount, because over-exposed data is one of the most common API failures there is.

Active testing (DAST for APIs). Now you send things a normal client would not: malformed inputs, injection strings, id values that aren't yours. This is what surfaces injection-class bugs and, with a valid session, the BOLA case above where you swap 1002 for 1003. It pushes on the endpoint instead of just reading it, so it finds things a passive read cannot.

Authenticated and business-logic testing. The deepest form, usually a human. A tester holds real credentials, understands that order_id 1003 belongs to a different customer, and chains small gaps into a real breach. Scanners pattern-match; a person reasons about your specific app.

The slice you can check from outside, right now

Here is the honest boundary, because it decides what a free external check is worth to you. A passive scan sees your API the way an unauthenticated stranger does. It never logs in and never sends an attack, so it will not find the BOLA case that needs a valid session, and it will not test your business logic. What it does find is the exposure slice, and that slice is real.

That passive half is not a consolation prize. Over-exposed responses and reachable secrets are among the most common API problems, and they are the ones a bot finds first because they need no skill: just replay the request the page already made and read the answer. Closing them removes the cheapest attack before anyone has to think.

Where to start

If you have never looked at your API from outside, start there, because it is free and it catches the exposure class fast. Open your live app in an incognito window, watch the network tab, and for every response that carries data ask whether a logged-out visitor should see it. That is the same read a passive scan automates.

SurfaceCheckr runs exactly that passive read: it captures the API calls your frontend makes, checks each response for over-shared fields, leaked secrets, and error-page leakage, and grades what it finds, all without a login or a payload. It is deliberately not the whole picture. When you need the authenticated and business-logic half, the BOLA swap and the injection behind a password, that is DAST-and-pentest work, and we say so. But the exposure slice is where most APIs are actually leaking, it is readable from the open internet, and it is the right first thing to close. If your API hands back more than it should, the broken-access-control writeup shows exactly how that looks from the browser.