API security testing: a 2026 guide to the OWASP API Top 10

API security testing is the practice of checking an API's authentication, authorisation, input handling, limits and configuration for flaws before an attacker finds them. Start with the OWASP API Security Top 10 (2023), prepare two or more test accounts, replay each request with the wrong account, and keep a proof for every finding.

The worst API bugs are missing checks: an endpoint that returns another customer's invoice, an admin function a normal account can call, a field a client should never set. A scanner finds some. A person, or a tool that understands your application, finds the rest. Below are the method, a test for each OWASP risk and a plan to repeat it every release.

What is API security testing, and how is it different from testing a website?

API security testing sends deliberately chosen requests to an API and judges the responses against what the caller should be allowed to do. A website test follows pages and forms. An API test works on endpoints, methods, tokens, identifiers and JSON bodies, often with no user interface to guide you.

That changes the work in three ways. First, the client is not the control: anything a mobile app or single-page app hides can still be sent by hand. Second, APIs expose raw objects, so authorisation mistakes show up as data. Third, there is often no complete map of endpoints, so finding them is part of the test.

Which methods can you use?

No single method covers an API. The table shows what each one is good at.

For a wider comparison see our guide to DAST, SAST and IAST. For how API tests sit inside a full engagement, read the web application penetration testing guide.

Why does API security testing matter in 2026?

It matters because APIs carry the data and the actions, so a missing check is a breach, not a cosmetic bug. The Verizon 2026 Data Breach Investigations Report says 31% of breaches now start with software vulnerabilities, ahead of stolen passwords as the top way in.

Survey data from API-focused vendors points the same way, though it comes from a security vendor's own respondents and should be read as a signal rather than a census. In its H2 2025 State of API Security Report, Salt Security surveyed 386 security professionals. It reports that 33% had an API security incident in the past year, 80% lack continuous, real-time API monitoring, and only 19% are very confident in the accuracy of their API inventory. It also found that 54% rely on developer documentation, which goes stale, to identify sensitive data exposure.

You cannot test an endpoint you do not know exists, which is why API9 is a testing problem as much as a governance one.

What should you prepare before an API security test?

Prepare four things: a list of endpoints, test accounts that differ in privilege and tenant, a safe environment, and written rules for what may be sent.

The pre-test checklist

Why two accounts in different tenants?

Most serious API flaws need a second identity. Account A creates an object and records its ID. Account B asks for that ID. If B receives it, you have a cross-account access flaw and the proof. Add a lower role in the same tenant for function-level checks. Our guide to access control testing shows how to plan these accounts and what to record.

What is the OWASP API Security Top 10?

The OWASP API Security Top 10 is a ranked list of the ten most critical API risks, maintained by the OWASP community. The current edition is 2023. It differs from the general OWASP Top 10 because it concentrates on authorisation, resource limits and API-specific abuse. Our Knowledge Hub entry on the OWASP API Top 10 gives a short definition.

The ten risks and the first test for each

Three of the ten are authorisation risks (API1, API3 and API5), and a fourth, API6, is about abusing allowed functions. If your time is short, spend it there.

How do you test for BOLA, BFLA and property-level flaws?

You test them by replaying the same request with a different identity and comparing what comes back. These three risks, API1, API5 and API3, are where most high-severity API findings live, and a scanner without two accounts cannot see them.

The three authorisation tests

API1: Broken Object Level Authorization (BOLA)

BOLA means an endpoint that takes an object identifier does not check that the caller may use that object. OWASP says any endpoint that takes an object ID and acts on that object needs its own object-level authorization check. Its risk table rates exploitability as easy and prevalence as widespread. BOLA is the API form of IDOR; our BOLA explainer and IDOR checklist go deeper.

1. As account A, create an object and note its ID, for example GET /v2/invoices/8841.
2. As account B in another tenant, send the same request with B's token.
3. Repeat for every method that accepts the ID: read, update, delete, and sub-resources such as /invoices/8841/pdf.
4. Look for IDs outside the path: query strings, JSON bodies, headers, and batch endpoints that take a list of IDs.
5. Try an ID that does not exist and an ID that belongs to someone else. If the errors differ (404 against 403), you have an enumeration signal.

Do not treat random IDs as a fix. OWASP prefers unpredictable GUIDs but lists them as one measure among several; the check on the server is the control. Long random IDs also leak through logs, emails and shared links.

API5: Broken Function Level Authorization (BFLA)

BFLA means a caller can reach a function their role should not reach. OWASP's test questions are practical: can a regular user reach administrative endpoints, can a sensitive action be performed by changing the HTTP method from GET to DELETE, and can a user in one group reach a function meant for another by guessing a URL such as /api/v1/users/export_all?

1. Collect every admin and internal route from the spec, the front-end bundle and the gateway configuration.
2. Call each with a low-privilege token, then with no token.
3. Swap methods on every route; PUT, PATCH and DELETE are often less guarded than GET.
4. Check versioned paths. A fixed /v3 route can leave /v1 open.

The fix OWASP recommends is to deny all access by default and grant functions to specific roles explicitly.

API3: Broken Object Property Level Authorization

This risk covers two directions. The API returns fields the caller should not see, or it accepts writes to fields the caller should not change. The second is mass assignment. OWASP's guidance is to cherry-pick returned properties instead of using generic to_json() style methods, and to allow changes only to properties the client should update.

1. Read the same object as an owner, a different tenant's user and an admin. Diff the field lists.
2. In a profile or order update, add fields such as role, isAdmin, price, tenantId or status.
3. Re-read the object to confirm whether the value was accepted, since some APIs return 200 and ignore the field.

What does a pass and a fail look like?

How do you test API authentication (API2)?

Test authentication by trying to be believed without proof: no token, a changed token, an old token and a guessed credential. API2 lists failures such as accepting unsigned or weakly signed JWTs, not validating the expiry date, putting tokens in the URL, and allowing unlimited password attempts.

Token tests

JWT checks

The OWASP REST Security Cheat Sheet says to validate the issuer (iss), audience (aud), expiry (exp) and not-before (nbf) claims. Test each: change aud to another service, send an expired token, set the algorithm to none, and strip the signature. Any 200 response is a finding.

OAuth and session checks

If you use OAuth, compare the flow to RFC 9700, the OAuth 2.0 security best current practice. It requires exact string matching of redirect URIs, expects PKCE for public clients, discourages the implicit grant, and asks for refresh token rotation or sender-constraining for public clients. Test a near-match redirect URI, a replayed authorisation code, and a refresh token used twice.

Brute force and recovery

Send repeated failed logins and password resets and confirm lockout, throttling or a challenge appears. Check that changing an email address or phone number asks for the current password, as OWASP advises. An API key identifies an application; OWASP states keys should not be used to authenticate users.

How do you test resource limits and business-flow abuse (API4 and API6)?

Raise the load and the repetition in controlled steps, and record where the API stops you. API4 lists the limits to look for: execution timeouts, memory, maximum upload size, operations per request, records per page and third-party spending limits.

Resource consumption (API4)

• Ask for ?limit=100000 and note whether the server caps it.
• Upload a file above the stated size.
• Send a batch of operations in one request, such as 500 items in a bulk endpoint.
• Call an endpoint that triggers SMS, email or a paid third-party call and see whether a spending cap exists.
• Check that rate limiting differs by endpoint: login and OTP checks need tighter limits than reads.

Sensitive business flows (API6)

API6 is about legitimate functions used at harmful scale: purchases that enable scalping, comment creation that enables spam, reservations that let one party hold all stock. OWASP's advice has a business layer, identifying flows that would hurt the business if overused, and an engineering layer, such as device fingerprinting and human detection.

List your five most valuable flows (sign-up, coupon redemption, checkout, referral, password reset) and script each at a modest volume. If nothing slows the script, you have a finding. This overlaps our business logic testing checklist.

How do you test SSRF, misconfiguration, inventory and third-party risks (API7 to API10)?

These four risks are about what surrounds your code: URLs it fetches, how it is configured, which versions are reachable, and which other APIs it trusts. Each has a simple first probe.

The four surrounding risks

API7: Server Side Request Forgery

SSRF appears wherever an API fetches a user-supplied URL: webhooks, image imports, link previews, PDF generators. Supply an address you control and watch for the callback. Then try internal ranges and cloud metadata addresses on a staging host. OWASP recommends allowlists for origins, schemes, ports and media types, disabling HTTP redirections and using a well-tested URL parser.

API8: Security Misconfiguration

Send malformed JSON, wrong content types and oversize bodies. The REST cheat sheet expects 405 for disallowed methods, 415 for unsupported content types, 413 for oversized requests and 429 when limits trigger. Check for stack traces in errors, missing TLS, and a permissive CORS policy that reflects any origin with credentials allowed.

API9: Improper Inventory Management

Look for older versions (/v1, /beta), forgotten hosts (api-staging, old-api) and debug routes. OWASP asks you to inventory all API hosts and document each one, and to avoid using production data on non-production deployments. Unretired versions are zombie APIs; routes nobody documented are shadow APIs. Our guide to the API inventory term explains the control.

API10: Unsafe Consumption of APIs

Your API trusts other APIs too. Stand up a stub of a partner or webhook source that returns oversize bodies, unexpected fields, redirects to internal addresses and slow responses. OWASP says to validate and sanitise data from integrated APIs, use TLS, set timeouts for third-party calls and not follow redirects blindly.

The table lists the proof to keep for a finding, and the proof that closes it, by risk.

How do you test a GraphQL API?

Test a GraphQL API for the same ten risks, plus the problems its single endpoint creates. The OWASP GraphQL Cheat Sheet tells you to validate input, block expensive queries, check access control and change insecure defaults, and warns that GraphQL often ships with introspection switched on and no authentication in front of it.

• Introspection and suggestions: the cheat sheet advises disabling introspection in production and turning off field-name suggestions. Query __schema and note what leaks.
• Depth and amount limits: send deeply nested queries and requests for large lists. The cheat sheet recommends depth limiting, amount limiting and timeouts.
• Batching: send many aliased login or lookup operations in one request to see whether per-request rate limits are bypassed.
• Authorisation per field: the cheat sheet warns that possession of an object's ID does not mean the caller should have access. Run the BOLA test through queries and mutations alike.

Which API security testing tools and approaches should you use?

Use a mix: an intercepting proxy and an API client for manual work, a schema-driven fuzzer for breadth, a dynamic scanner for baseline checks, and a pentest for the authorisation and logic flaws that tools miss.

Where white-box and grey-box access helps

With credentials and the source code, testing gets faster and more accurate. Cyberlop finds vulnerabilities in web apps and their APIs with black-box, grey-box and white-box pentesting. In white-box mode it reads your code while testing the running app, so a finding can point to the file and line, and it checks cross-account access and business-logic flaws. It reports what it actually exploited, with the request and response as evidence. See how it works and what a finding looks like, and the guide on exploited, not suspected findings.

In what order should you run an API security test?

Run cheap, broad checks first and careful ones last.

1. Inventory and accounts: endpoint list, test accounts, seed data, written permission.
2. Unauthenticated sweep: call every endpoint with no token. Anything that answers should be public on purpose.
3. Authentication (API2): tokens, login, recovery, sensitive changes.
4. Objects and properties (API1, API3): two accounts in two tenants.
5. Functions (API5): each privilege level, across methods.
6. Input and fetch (API7): injection, URL fields, file handling.
7. Limits and flows (API4, API6): in small, agreed steps.
8. Configuration, versions, third parties (API8 to API10).
9. Report, fix, retest.

How often should you run API security tests, and how do you fit them into CI/CD?

A common pattern is a full manual test at least yearly and after major changes, with automated checks on every build. No standard fixes the interval; match it to how fast your API changes. Our guide to continuous penetration testing covers the cadence in detail.

A practical cadence

• Every pull request: unit tests that assert authorisation (account B gets 403 on account A's object), plus static analysis.
• Every deploy to staging: schema-driven checks and a dynamic scan; gate the build on new high-confidence findings.
• Quarterly or on a major release: a pentest with at least two tenants and an admin account.
• Continuously: inventory checks that compare the routes seen in traffic with the routes in the spec.

The OWASP BOLA guidance says it plainly: write tests that evaluate the authorisation mechanism and do not deploy changes that make the tests fail. Cyberlop can run on a schedule or in CI/CD and gate a build; see integrations.

How do you prove an API fix works?

Replay the exact failing request against the fixed code and show the new response. A fresh scan that stays quiet is not proof, because the scan may never have sent that request. Keep the exploit as a regression test.

1. Store the failing request and response with the finding.
2. Fix the check on the server, not in the client.
3. Replay the same request with the same token; expect 403, 404 or a rejected field.
4. Add the replay to the test suite.
5. Close the ticket with the before and after responses attached.

Cyberlop proves a fix by re-running the exact exploit against the new code (a closed-loop retest), not by a fresh scan.

What mistakes make an API security test miss things?

• One account. Authorisation flaws cannot be seen from a single identity.
• Trusting the interface. A hidden button proves nothing about the endpoint behind it.
• Documented routes only. The risky ones are often not in the spec.
• Reading status codes alone. A 200 can be correct or a leak; compare bodies across accounts.
• Treating a clean scan as a pass. It means the scanner found nothing it knows how to find.