APIs now carry most of the traffic that matters: mobile apps, single-page frontends, partner integrations and service-to-service calls all run on them. That also makes them where most real attacks land. An API has no UI to hide behind: every object, parameter and workflow is exposed directly to anyone who can send an HTTP request, and the guardrails a browser gives you simply are not there. API penetration testing attacks those endpoints the way a motivated adversary would, to find the authorisation gaps, injection flaws and business-logic abuses that automated scanners miss. This guide covers why APIs are such a rich target, the OWASP API Security Top 10, how we test an API end to end, the tools we use, and what you get in the report. If you want this against your own stack, see our API penetration testing service.
Table of contents
Why APIs Are a Prime Target
Gartner called it years ago: APIs are now the single largest attack surface for most web-enabled applications, larger than the user interface. The reasons are consistent across the engagements we run:
- No UI guardrails. Fields hidden in a web form are still accepted by the API behind it. Role checks enforced in JavaScript mean nothing to a client that talks straight to the backend.
- Rich, structured data. APIs are built to return data efficiently, which often means returning more than the frontend displays: internal flags, other users’ records, full object graphs.
- Predictable, automatable surface. Identifiers increment, schemas are documented, and requests are trivial to script. What a tester can do by hand, an attacker can do ten thousand times.
- Under-tested. API versions ship faster than they are reviewed. Shadow and deprecated endpoints linger long after anyone remembers they exist.
A single broken endpoint is enough. We have turned one unauthenticated identifier leak into a full account-takeover chain more than once. The Yunmai smart-scale case study below is a textbook example.
The OWASP API Security Top 10 (2023)
The OWASP API Security Top 10 is the framework we map every finding against. It is deliberately different from the web-app Top 10: authorisation dominates it, because that is where APIs actually fail.
| ID | Risk | What it means |
|---|---|---|
| API1 | Broken Object Level Authorization (BOLA) | Swap an ID, read someone else’s object. The most common and most damaging API flaw. |
| API2 | Broken Authentication | Weak, missing or bypassable login, token and reset flows. |
| API3 | Broken Object Property Level Authorization | Reading or writing fields you shouldn’t; it combines the old “excessive data exposure” and “mass assignment”. |
| API4 | Unrestricted Resource Consumption | No rate or size limits, enabling brute force, scraping and cost/DoS abuse. |
| API5 | Broken Function Level Authorization (BFLA) | Calling admin or privileged functions as a lower-privileged user. |
| API6 | Unrestricted Access to Sensitive Business Flows | Automating a flow (checkout, booking, signup) in a way the business never intended. |
| API7 | Server-Side Request Forgery (SSRF) | Making the server fetch an attacker-controlled URL: cloud metadata, internal services. |
| API8 | Security Misconfiguration | Verbose errors, permissive CORS, missing hardening, exposed debug endpoints. |
| API9 | Improper Inventory Management | Shadow, deprecated and undocumented endpoints and environments. |
| API10 | Unsafe Consumption of APIs | Blindly trusting data from third-party APIs you integrate with. |
How We Test an API
A good API test is not a scan. It is a structured walk through the surface, led by whatever the application actually does. This is the methodology we run on every engagement.
1. Reconnaissance and endpoint discovery
What we look for: every endpoint, including the ones not in the docs. We pull routes out of frontend JavaScript and mobile binaries, enumerate subdomains like api. and dev-api., and hunt for exposed OpenAPI/Swagger definitions, Postman collections and GraphQL introspection.
How we test: an exposed schema is a map of the whole attack surface, so we always try introspection on GraphQL and paths like /swagger and /openapi.json first. Where there is no schema, we brute-force paths and parameters, and compare documented versus live endpoints to surface shadow and deprecated APIs (API9).
2. Authentication and authorisation
This is where most of the real findings are, so it gets most of the time.
BOLA (API1): authenticate as user A, then systematically substitute user B’s identifiers across every object-bearing endpoint: numeric IDs, UUIDs, and GraphQL node(id:) lookups. We watch the difference between “not found”, “forbidden” and “here’s the data”.
BFLA (API5): we map which functions each role is supposed to reach, then call the privileged ones (admin, export, delete) from a low-privileged session. Backends that rely on the UI to hide a button fail here routinely.
Tokens: we test JWTs for alg:none, algorithm confusion (RS256→HS256), signature stripping and reuse after logout; OAuth flows for redirect_uri abuse, scope and audience validation and token leakage; and API keys for predictability, privilege scope and missing restrictions.
3. Injection and input validation
What we look for: anywhere input reaches a query, a shell, a template or a parser: SQL and NoSQL injection (including JSON operator injection like {"$ne":null}), command injection, server-side template injection, XXE on SOAP/XML endpoints, and insecure deserialization.
How we test: we fuzz every parameter, not just the obvious ones, with type mismatches and payloads tuned per sink, and confirm blind cases with time delays and out-of-band callbacks. API3-class property flaws get special attention: we try to write fields the client never sends (mass assignment: isAdmin, role, verified) and to read fields the UI never shows.
4. Business logic and sensitive flows
What we look for: abuse that uses the API exactly as designed but in an order or volume nobody intended: replaying one-time actions, skipping steps, manipulating price or state mid-flow, or automating a sensitive flow (API6) like checkout or account creation.
How we test: these can’t be scanned for. We model the intended workflow, then deliberately break its assumptions: invoke step B without step A, replay a confirmation token, apply a coupon twice, change a plan’s price in the update call. This is the work that separates a manual test from a tool run.
5. Rate limiting and resource consumption
What we look for: missing or bypassable throttling (API4). Login, OTP, search and export endpoints are the usual suspects.
How we test: we push volume and watch for 429/403, then try the standard bypasses: rotating IPs and tokens, X-Forwarded-For spoofing, user-agent rotation and headless browsers against JS challenges. On GraphQL we also test query batching and deeply nested queries as both a rate-limit bypass and a DoS vector.
6. Data exposure and misconfiguration
What we look for: objects that return more than they should (API3), verbose errors and stack traces (API8), permissive CORS, SSRF-able URL fetchers (API7), and secrets in responses, logs or error bodies.
How we test: we read full responses, not just the fields the UI consumes, and diff responses across privilege levels. For SSRF we target any feature that fetches a URL on the server’s behalf (webhooks, PDF and screenshot generators, image imports) and aim first at cloud metadata endpoints.
REST, GraphQL and SOAP: What Changes
The methodology is constant; the mechanics shift with the API style.
| Style | Where testing focuses |
|---|---|
| REST | BOLA/BFLA via ID and method tampering, mass assignment, over-broad responses. The bread and butter of API testing. |
| GraphQL | Introspection and field suggestions, field-level authorisation gaps, query batching, alias-based bulk extraction, and nested-query DoS. One endpoint, many ways in. |
| SOAP / XML | XXE, WS-Security misconfiguration and SOAPAction spoofing, usually in legacy and enterprise systems. |
| gRPC / WebSockets | Weak or absent per-message authorisation, message-validation flaws, and real-time abuse on long-lived connections. |
Tools We Use
Tools accelerate the work; they don’t replace the tester. The ones that earn their place on API engagements:
- Burp Suite: the core proxy, with Autorize for authorisation testing, Turbo Intruder for high-speed fuzzing, and InQL for GraphQL.
- Postman / Insomnia: building and chaining requests, importing OpenAPI specs, managing auth across multi-step flows.
- ffuf, Kiterunner, Arjun: endpoint and parameter discovery, with Kiterunner’s API-aware wordlists.
- Nuclei, OWASP ZAP: templated checks and OpenAPI-driven coverage, used to cover ground, not to conclude.
- jwt-tool, sqlmap, interactsh: token attacks, injection confirmation, and out-of-band detection for blind SSRF and injection.
- Custom Python/Go: stateful exploit chains and bespoke enumeration when off-the-shelf tooling can’t model the logic.
What You Get: The Report
The deliverable is a report an engineer can act on, not a scanner dump. Each finding carries the affected endpoint(s), a severity rating against both CVSS and OWASP, the business impact in plain language, copy-pasteable reproduction steps (we include curl where it helps), and a specific remediation. An executive summary frames the risk for stakeholders; findings are prioritised so authorisation and data-exposure issues come first. Where a scanner-grade “medium” actually exposes salary or health data, we say so; context changes severity.
Our API Hacking Case Studies
The methodology above is drawn from real engagements and research. A few public write-ups:
- Access-control vulnerabilities in the Feeld dating app’s GraphQL API
- Mass account takeover in the Yunmai smart-scale API
- Compromising Plesk via its REST API
FORTBRIDGE is a CREST-accredited penetration testing company. We break and secure APIs across REST, GraphQL, SOAP and gRPC, with deep manual testing that goes well beyond what any scanner finds, and reports your developers can actually use. If you want to understand your API security exposure, get in touch, or learn more about our API penetration testing service.
Frequently Asked Questions
What is API penetration testing?
API penetration testing is a security assessment in which testers attack an application’s APIs (REST, GraphQL, SOAP and others) to find vulnerabilities such as broken authorisation, injection and business-logic flaws before an attacker does. It targets the endpoints directly, rather than through a user interface.
How is API pentesting different from web application pentesting?
A web application test drives the app through its UI and browser behaviour. API testing talks straight to the backend, where none of the UI’s client-side checks apply. Authorisation flaws (BOLA, BFLA) dominate API findings in a way they don’t in traditional web testing, so the methodology weights them heavily.
What is BOLA, and why does it matter so much?
Broken Object Level Authorization (API1) is when an API returns an object without checking that the caller owns it: change an ID in the request and you read someone else’s data. It is the most common serious API vulnerability because the fix is per-endpoint discipline that is easy to miss, and the impact (mass data exposure or account takeover) is high.
How long does an API penetration test take?
It depends on the number of endpoints, the API styles in scope, and how many user roles need authorisation coverage. A focused API is typically a few days; a large platform with many roles and GraphQL takes longer. We scope from your OpenAPI spec or a short discovery call.
Can automated API scanners replace a manual test?
No. Scanners are good at misconfigurations and known patterns, and we use them for coverage. But BOLA, BFLA and business-logic abuse require a human who understands what the application is supposed to do. Those are the findings that matter most, and they are exactly what automation misses. See manual vs automated penetration testing.
About Post Author
