API Security Testing Basics

If your application serves data to mobile apps, integrations, or frontend clients over HTTP, it has an API. And if it has an API, it probably has security problems you haven't found yet.

API security testing is fundamentally different from web-app testing. There's no UI to click through. There's no browser to protect you. The attacker is a piece of code that can send thousands of requests per second, and it doesn't care about UX friction.

Why APIs are a different attack surface

A web browser gives you a lot of security "for free" because it's a regulated environment. The Same-Origin Policy, CORS, cookies with HttpOnly flags — the browser enforces these. An attacker using the browser is constrained.

An API client is not. It's just code making HTTP requests.

No browser protection. A machine client doesn't care about CORS headers. It doesn't store cookies if you don't want it to. It can send malformed JSON, tampered tokens, and requests you never anticipated because it's not constrained by a UI.

No user context. Web apps show different UI based on who's logged in. APIs often show different data based on who's requesting it. If the API doesn't properly validate permissions on each request, it leaks.

Scale. A browser is one request at a time, limited by human clicking speed. An API attacker can send 10,000 requests/sec and enumerate every resource. Rate limiting and pagination are security controls most teams don't build right.

This is why the OWASP API Top 10 exists. It's a separate list from the web top 10.

The OWASP API Top 10 (and what each one means)

1. Broken Object-Level Authorization (BOLA) — The API returns data based on an ID in the URL (/api/users/123), but it doesn't check if the requesting user owns user 123. Attacker increments the ID and reads someone else's data. This is the most common API vulnerability.

2. Broken Authentication — The API accepts invalid or missing auth. Maybe the token isn't validated. Maybe it's validated client-side only. Maybe the endpoint checks one header but not another. An attacker gets access without credentials.

3. Broken Object Property Level Authorization — The API returns all properties of an object when you only have permission to see some. You request a user object and get their password hash, even though that's not public data.

4. Unrestricted Resource Consumption — The API has no rate limits or pagination limits. An attacker floods it with requests or fetches the entire database in one query. The server dies or goes bankrupt on cloud costs.

5. Broken Function Level Authorization — You can't delete users in the web UI, but the /api/users/{id} DELETE endpoint doesn't check permissions. An unauthenticated attacker can delete anyone.

6. Unrestricted Access to Sensitive Business Flows — The API lets you call functions out of order or in ways the UI prevents. Maybe you can checkout without adding items to the cart. Maybe you can transfer money to yourself infinitely.

7. Server-Side Request Forgery (SSRF) — The API makes HTTP requests on your behalf (to fetch a URL, load an image, etc.) but doesn't validate the target. An attacker makes the server request internal IPs, cloud metadata endpoints, or other sensitive systems.

8. Security Misconfiguration — Debug endpoints left on in production, error messages that leak database structure, CORS headers that are too permissive, or frameworks running with default credentials.

9. Improper Inventory Management — You don't know all your APIs. Old versions you forgot to deprecate, internal APIs that are accidentally public, or shadow APIs built by different teams. An attacker finds the one you forgot.

10. Unsafe Consumption of APIs — Your backend calls another API (Stripe, a vendor, etc.) but doesn't validate the response, doesn't timeout, or trusts it implicitly. An attacker hijacks the external API or makes your backend do something bad.

Most of these don't show up in a web-app pentest. They're API-specific because the attack surface is different.

What API security testing finds (and what it looks like)

A good API security test probes each endpoint with:

• Missing auth — Do you require a token? Does the endpoint work without it?
• Invalid auth — Does a wrong token still get through? An expired token? An empty token?
• Wrong user's data — Can I request user 2 when I'm logged in as user 1?
• Tampered IDs — Can I change /api/orders/123 to /api/orders/999 and see someone else's order?
• SQL injection — Does the API concatenate user input into queries? (/api/search?q='; DROP TABLE users; --)
• Injection at the API layer — JSON injection, XML injection, command injection through fields you don't think are dangerous.
• Business logic flaws — Can I checkout twice with the same token? Can I transfer money to myself? Can I call endpoints in the wrong order?
• Mass assignment — The API sets fields you didn't ask it to set. You submit {"username": "alice"} and it sets {"username": "alice", "is_admin": true}.
• Rate limits — Can I enumerate all users by looping through IDs? Is there pagination without a size limit?

When testing finds these, the output should be:

Reproducible exploit code. Not "SQL injection possible" but a curl command or a script that proves it works. Example:

POST /api/users/authenticate HTTP/1.1
Host: example.com
Content-Type: application/json

{"email":"admin@example.com","password":"' OR '1'='1"}

Expected: Authentication succeeds, returning an admin token.

Actual result: [token here]

This is what separates a good pentest report from vendor output. A CSV of vulnerability types is not actionable. A working exploit is.

How to test an API (three approaches)

Manual testing + Burp Suite or Postman

You craft requests by hand, send them, and look for unexpected responses. Fast for initial exploration. Slow for thorough coverage because you're one person and the API probably has 50+ endpoints.

Good for: small APIs, focused testing on specific endpoints, understanding how the API actually works

Bad for: comprehensive coverage, systematic testing of all endpoints + all auth states

Spec-driven testing

You feed the API's OpenAPI/Swagger spec to a tool (like Burp's API Scanner), which automatically generates requests to every endpoint with various payloads. The tool then looks for anomalies (error messages that leak info, unexpected status codes, etc.).

Good for: scanning all endpoints fast, systematic coverage, finding obvious misconfiguration

Bad for: business-logic flaws, complex exploitation chains, context-aware attacks

Agentic testing

An AI agent reads your API spec (or introspects your API), generates requests intelligently based on what it learns, adapts to responses, and chains exploits. Cipher uses this model. It can find BOLA in one endpoint, then use that access to escalate privileges, then use those privileges to exploit a second endpoint. It thinks like a manual tester but runs 24/7.

We tested this against real API targets — the OWASP crAPI benchmark and the XBOW benchmark suite — and found complex chains of vulnerabilities that neither manual nor scan-based testing found in the same time window.

Good for: complex chains, business-logic flaws, finding exploits not on any checklist, iterative assessment

Bad for: sometimes slower on simple, obvious things

What a good API pentest looks like

• Coverage: Every endpoint tested with multiple auth states (no auth, wrong user, expired token, etc.)
• Depth: Not just "endpoint X has BOLA," but "if you exploit it this way, you can read 50k customer records"
• Chains: Multiple vulnerabilities chained into a single exploit
• False positives: Filtered out. The report doesn't say "injection detected" if you couldn't actually inject anything
• Passed tests: The report lists endpoints that were tested and found secure, not just the broken ones
• Retest: You fix the findings, they test again, findings gone

If the report is mostly CSVs of findings, it's probably just tool output. That's fine for a baseline, but it's not a pentest.

The API security testing decision tree

You don't have an API spec or it's not documented: Start with agentic testing or manual exploration. The tool needs to learn your API first.

You have a spec (OpenAPI/Swagger): Spec-driven scanning to find obvious issues. Then run an agentic assessment or manual testing for chains and business logic.

You're raising capital or selling to enterprises: Agentic assessment or manual pentest. They'll ask for it, and a tool output won't satisfy them.

You want to test every sprint: Agentic testing. Manual pentest every 6 months for a deep dive; agentic tool continuously.

You just built new endpoints: At minimum, run a spec-driven scan on the new ones. Ideally, run an agentic assessment.

---

Next: How to choose the right tool for your API. Read the pentest tool buyer's guide →

Deep dive: See how Cipher tested real API challenges — 86.7% of XBOW vulnerabilities, plus 95 additional findings.

Try it: Run your first API security assessment →