API Penetration Testing: What It Covers and How to Run It Continuously

An API has no screens to hide behind. Every object, every function and every field is one HTTP request away, which is why most serious API bugs are about access, not injection. An API pentest asks one question over and over: can this caller do something they shouldn't?

What is API penetration testing?

It's a hands-on security test of an API's endpoints. The tester (a person, an AI agent or both) finds the endpoints, logs in as real users, then changes IDs, roles, fields, tokens and request rates to see what the API lets through. A scanner looks for known patterns. A pentest checks whether a weakness can actually be used, and against whose data.

The OWASP API Security Top 10 (2023)

The OWASP API Security Top 10 is the standard reference. The 2023 edition is still the current list (checked 2026-09-26 on owasp.org).

The API bugs that matter most

BOLA and IDOR

Broken object level authorization (the API name for IDOR) is the most common serious API finding. GET /api/v2/orders/8812 returns an order. Change it to 8813 and you get someone else's. It happens because authentication says who you are, and nothing then checks that the object is yours. UUIDs don't fix it, they only make IDs harder to guess, and they leak in other responses anyway. Testing it properly needs two accounts of the same role, so the tester can try one user's objects with the other's token.

BFLA

Broken function level authorization is the vertical version. A regular user calls DELETE /api/users/42 or POST /api/admin/refunds and it works, because the check lives in the admin UI, not in the API. Testing it needs a low-privilege account and knowledge of what the higher roles can call.

Mass assignment

Frameworks that bind JSON straight onto a model will save any field that matches. A profile update that sends {"name": "Ana", "role": "admin"} shouldn't make Ana an admin. The pentest adds fields the client never sends and checks, with a second read, whether they stuck.

Broken authentication and JWT

Tokens are the API's front door. Common findings are JWTs accepted with alg: none, HMAC secrets short enough to crack, tokens that never expire or survive logout, API keys in URLs, and login endpoints with no lockout.

Rate limits and resource consumption

A missing rate limit on login or OTP means password guessing and code brute force. On search or export, it means scraping and cost. The test bursts those endpoints and looks at whether the API ever pushes back. GraphQL adds its own form: one request with hundreds of aliases or batched queries.

SSRF

Any feature that fetches a URL for the user (webhooks, avatars from a link, PDF rendering, imports) can be pointed at internal services or cloud metadata. The pentest tries those parameters with addresses the server shouldn't reach and watches for a sign the request was made.

REST vs GraphQL: what changes

A GraphQL test needs care with mutations. They run as soon as they're sent, so a careful test reads data to prove access and doesn't fire mutations against live data.

Why authenticated, multi-role testing matters

An unauthenticated API test mostly sees login endpoints and error messages. The bugs above live behind the login, and most of them only show up when you compare two identities.

• Two users with the same role find BOLA: can user A read user B's order?
• A user and an admin find BFLA and privilege escalation: can the user call what only the admin should?
• Each role's view of the same object finds excessive data exposure: does the user get fields only the admin should see?

So give the tester at least two accounts in the same role and one in each higher role you have, with test data in each. It's the single biggest factor in what an API pentest can find.

What a good API pentest report contains

A finding without the request and response behind it is hard to reproduce and easy to argue with. The sample report shows the layout we use.

How often should you test an API?

APIs change more often than almost anything else in a product, and each change can add a route without a check. A test from last year describes an API you no longer run.

1. Continuously. A pentest reruns on a schedule or after each deploy, and each run labels findings new, still open, fixed or regressed. This is what catches the ownership check someone removed in a refactor. Security regression testing explains the labels.
2. On a schedule. Monthly or quarterly runs give a steady record, which also helps with SOC 2 evidence and customer security reviews.
3. On demand. Before a major launch, a new partner integration, or when a customer asks for a recent report.

How often to pentest goes through cadence by app type.

Running API pentests from CI/CD

Most API bugs ship in a normal release: a new route without an ownership check, a serializer that picks up a new field. So the natural trigger is the pipeline. A pentest can start from your CI/CD pipeline via the Barrion API after a deploy to staging or production, without blocking the build. Findings arrive when the run finishes, labelled against the previous run.

How Barrion tests APIs

Barrion's AI agents test web apps and APIs the way an attacker would, across 8 testing areas, covering all 97 OWASP WSTG v4.2 test cases and the OWASP API Security Top 10. When you pick an API as the target, the run changes shape:

• API-first order. Reconnaissance, API security, access control and authentication run first, then injection and session handling. Tests that only make sense in a browser, like DOM-based client-side checks and file upload, are left out.
• Endpoint discovery. The agent checks common paths for a published OpenAPI or Swagger file (such as /openapi.json and /v3/api-docs) and, if it finds one, uses every path, method and parameter in it. It also reads endpoints out of crawled pages and JavaScript bundles.
• Authenticated, multi-role runs. Add test users with a username and password (with an authenticator-app code if you use one), a bearer token or an API key in a header or query parameter. Each test user gets a privilege level, and the agent compares identities to find BOLA between peers and BFLA from a lower role to a higher one.
• Dedicated checks for BOLA, BFLA, mass assignment, JWT weaknesses (alg: none and weak HMAC secrets), SSRF through URL-shaped parameters, and missing rate limits. Rate-limit bursts only go to login, OTP and search endpoints, not to every route.
• GraphQL. When discovery finds a GraphQL endpoint, the agent checks introspection, per-resolver authorization across identities and alias or batch abuse. It reads data to prove access and never sends mutations.

Every finding is checked against the live app before it's reported. Confirmed ones come with the request and response behind them. Anything we couldn't confirm is clearly marked and capped in severity. Retests of found issues are free. From Standard up, a security engineer reviews the findings, and deeper tests come with a report signed off by that engineer. Data is stored and hosted in Sweden, and AI processing runs in the EU.

On the Business plan, API pentests can run on a schedule as well as on demand. Continuous programs are scoped to your APIs, cadence and depth, so talk to us for a price, or start with a single run from pricing. See AI pentesting for how the agents work, and what continuous pentesting is for the wider model.