API Penetration Testing — What is it and how does it work?

TL;DR — Is API pentesting the same as web app pentesting?

No, although the two are related. API Penetration Testing focuses on the application programming interface layer (REST, GraphQL, gRPC, SOAP) — directly on backend endpoints, ignoring the UI/HTML layer. A traditional web application pentest targets the browser HTML/JS layer and often misses backend endpoints used by mobile apps, SPAs and partner integrations. OWASP has maintained a separate API Security Top 10 since 2019 (with a second revision in 2023) because API vulnerabilities tend to differ fundamentally from those of classic web applications — BOLA, mass assignment and broken function level authorization dominate APIs, while XSS and CSRF are secondary. For a modern application (SPA + REST API + mobile clients) you generally need BOTH tests.

API pentest vs web app pentest vs network pentest — comparison

Aspect	API Penetration Testing	Web Application Pentest	Network / Infrastructure Pentest
Definition	Security testing of API endpoints (REST, GraphQL, gRPC, SOAP)	Security testing of a web application via UI/browser	Security testing of networks, servers and network devices
Scope	Backend endpoints, business logic, object-level authorisation	HTML forms, JavaScript, session management	Ports, network services, AD, VLAN segmentation, firewalls
Primary tools	Burp Suite, Postman, OWASP ZAP, kiterunner, Akto, 42Crunch	Burp Suite, OWASP ZAP, sqlmap, Nikto, browser DevTools	Nmap, Metasploit, BloodHound, Responder, Impacket
Top vulnerabilities	BOLA, broken auth, mass assignment, BFLA, SSRF	XSS, SQLi, CSRF, broken access control, IDOR	Lateral movement, missing segmentation, weak AD credentials, vulnerable services
Framework	OWASP API Security Top 10 (2023)	OWASP Top 10 (2021), OWASP ASVS	PTES, NIST SP 800-115, OSSTMM
Typical duration	5-15 working days	7-20 working days	5-15 working days
Typical price (PL 2026)	15-200k PLN net	20-150k PLN net	25-150k PLN net

In practice, modern audits combine these layers. A pentest of a single B2B SaaS may cover: the web app (admin panel), the API (REST + GraphQL for partner integrations), the mobile apps (with APK/IPA reverse engineering) and the cloud infrastructure (AWS/Azure IAM and configuration). A full nFlo audit is usually composed of several modules matched to the client’s architecture.

Definition of API Penetration Testing

API Penetration Testing is controlled, authorised security testing of application programming interfaces (Application Programming Interfaces) — REST, GraphQL, gRPC and SOAP — carried out by a qualified pentester from the perspective of a potential attacker. The pentester’s goal is to identify vulnerabilities in the API layer that could allow unauthorised access to other users’ data, privilege escalation, business logic manipulation, exfiltration of sensitive information or service disruption.

An API pentest differs from a web app pentest in its test layer (backend instead of UI), its discovery approach (Swagger/OpenAPI documentation instead of HTML crawling) and its reference framework (OWASP API Security Top 10 instead of the classic OWASP Top 10). It also differs from an API security review or API security audit, which usually refer to static analysis of code and configuration without active exploitation — a pentest is dynamic, hands-on testing with real attempts to exploit any vulnerabilities found.

In a compliance context, an API pentest is often required by frameworks such as PCI DSS Req 6.6 (for applications handling payment card data), NIS2 Art. 21 (for essential and important entities in the EU), DORA Art. 25 (for EU financial entities), the HIPAA Security Rule (for US healthcare entities) and ISO/IEC 27001 A.14 / A.8.29 (for certified organisations).

OWASP API Security Top 10 (2023) — the 10 key vulnerabilities

The OWASP API Security Top 10 is an industry-standard framework originally published in 2019 and revised in 2023. Any organisation running an API pentest should cover all ten categories.

API1:2023 — Broken Object Level Authorization (BOLA)

The most common API vulnerability. The attacker changes an object identifier in the request (/api/users/123/orders → /api/users/124/orders) and receives another user’s data, because the API does NOT verify whether the current user is authorised for the object with that ID. It appears in roughly 40-60% of API audits. Detection: for every endpoint with an ID, test with a different user_id, with an incremented ID, with a UUID belonging to another tenant. Mitigation: server-side checks on every request — NEVER rely on client-side filtering.

API2:2023 — Broken Authentication

Weaknesses in authentication mechanisms: JWT without signature verification or with alg: none, missing login rate limiting (password spray, credential stuffing), missing refresh token rotation, weak MFA implementation, no account lockout, password reset bypasses. The OWASP guidance is closely related to OIDC and OAuth best practice.

API3:2023 — Broken Object Property Level Authorization

Combines classic mass assignment (the client sends fields it should not be allowed to edit — PUT /api/users/me with isAdmin: true) and excessive data exposure (the API returns every field of the object in the response, including sensitive ones like password_hash, internal_notes, payment_method_token). Mitigation: explicit allow-lists of fields for both input and output, never deny-lists.

API4:2023 — Unrestricted Resource Consumption

No rate limits, no quotas, no limits on request body size, no timeouts on expensive operations. This enables DoS, scraping and costly abuse (for example when the backend pays per query to AI, third-party APIs or databases). GraphQL is particularly exposed through nested queries — a single query can trigger thousands of resolvers.

API5:2023 — Broken Function Level Authorization (BFLA)

A low-privilege user invokes administrative endpoints. The classic case: a regular user issues DELETE /api/admin/users/123 and the API does not verify the role. This typically occurs when authorisation is implemented only on the frontend (the admin panel hides the button, but the endpoint is reachable for any authenticated user).

API6:2023 — Unrestricted Access to Sensitive Business Flows

A NEW category in 2023. Automation of critical business flows: scalping (bots buying every promo item), fraud (bots abusing loyalty programmes), spam (bots mass-creating accounts). Mitigation: device fingerprinting, behavioural biometrics, CAPTCHA on sensitive flows, rate limiting per device/user.

API7:2023 — Server Side Request Forgery (SSRF)

The API fetches a URL supplied by the client (e.g. a webhook URL, an image URL to download and resize) and performs the request without validation. The attacker points to the AWS metadata endpoint (http://169.254.169.254/latest/meta-data/) or internal services (http://localhost:8080/admin) and may extract IAM credentials or attack internal APIs.

API8:2023 — Security Misconfiguration

Verbose error messages exposing stack traces and framework versions, debug mode enabled in production, missing security headers (HSTS, CSP, X-Content-Type-Options), default credentials, unrestricted HTTP methods (TRACE, OPTIONS), unprotected Swagger documentation in production.

API9:2023 — Improper Inventory Management

Old API versions (v1, v2) still reachable in production with known vulnerabilities, undocumented shadow APIs used internally, no inventory of environments (dev/staging exposed to the internet with prod-like data). Mitigation generally requires an API gateway with a central catalogue and regular audits.

API10:2023 — Unsafe Consumption of APIs

A NEW 2023 category — trusting third-party APIs without validating responses. If your API calls a partner and renders the result directly, a vulnerability in the partner can enable a chain attack (XSS, SSRF, deserialisation). Mitigation: validate every third-party API response as if it were user input.

API pentesting methodology (step by step)

A standard API pentest typically consists of eight phases, although in practice they iterate repeatedly.

1. Scope definition and pre-engagement

Agreement on scope, test roles (usually 2-3 accounts: anonymous/guest, low-privilege user, admin), environment (production vs staging), time window and emergency contacts. The client supplies API documentation (Swagger/OpenAPI specs, Postman collection or a HAR file from DevTools). The pentester requires dedicated test accounts and IP allow-listing so as not to collide with SOC monitoring.

2. API discovery and mapping

Inventorying every endpoint. Sources: official Swagger/OpenAPI documentation, traffic captured from a web application (Burp Proxy), traffic from a mobile app (mitmproxy + Frida to bypass certificate pinning), brute-forcing endpoint names (kiterunner with its 700k+ pattern wordlist), GraphQL introspection queries (where available), API gateway logs (if the client provides them).

3. Authentication and authorisation testing

Testing every authentication mechanism in use (Basic Auth, JWT, OAuth 2.0, OIDC, API keys, session cookies, mutual TLS) for: weak token generation, missing signature validation (JWT alg none), token reuse, timing attacks, missing rate limits, password reset bypass, missing MFA enforcement on sensitive operations. Plus BOLA (API1) and BFLA (API5) testing for EVERY endpoint with an ID or admin role.

4. Business logic abuse

The hardest and most valuable phase. The tester analyses business flows (registration, purchase, refund, fund transfer, loyalty programmes) and looks for abuse opportunities: race conditions (two simultaneous refunds), negative amounts, coupon fraud, workflow state manipulation (skipping steps), API6 sensitive business flows automation. Automated scanners essentially never catch issues at this layer.

5. Parameter tampering and injection

Classic injection attacks against API endpoints: SQL injection (sqlmap supports JSON/REST), NoSQL injection (MongoDB, CouchDB), command injection in endpoints with file processing, XXE in SOAP APIs, SSRF (API7), template injection in APIs that render documents, deserialisation attacks in APIs using pickle/Java serialisation.

6. Rate limiting and DoS testing

Testing limits: does login have a rate limit (password spray without account lockout), do expensive endpoints have quotas, does GraphQL enforce query depth/complexity limits, are there limits on request body size, are there limits on concurrent requests per user. This maps directly to API4 unrestricted resource consumption.

7. Configuration review

Checking security misconfiguration (API8): verbose errors, debug mode, security headers, exposed Swagger in production, default credentials, HTTP methods (TRACE, OPTIONS), CORS policy, exposed admin endpoints, exposed health/metrics endpoints (Prometheus, actuator), API versioning (API9 — old versions still reachable).

8. Reporting and retest

Final report with findings (CVSS scoring, business impact, proof of concept, remediation), executive summary for management, technical detail for developers. After the client applies fixes, a retest (typically 30-50% of the original price) verifies that the fixes work and have not introduced regressions.

API pentesting tools

The standard 2026 stack combines intercept/replay proxies, API clients for crafting precise requests, brute-forcers, fuzzers and automated scanners.

• Burp Suite Professional — the most widely used proxy with a rich extension ecosystem (JWT Editor, GraphQL Raider, Param Miner, Autorize for BOLA testing); effectively the de facto standard in the pentest community.
• OWASP ZAP — open-source alternative to Burp; weaker for fuzzing but has a solid API Scanner addon and good OpenAPI import.
• Postman / Insomnia / Bruno — API clients for building collections, inheriting authorisation and automating scenarios. Bruno, as the newer entrant, is often preferred for offline work (local file storage rather than cloud sync).
• Akto — open-source API security testing platform; scans traffic mirrored from the API gateway, identifies endpoints and automatically tests against the OWASP API Top 10.
• APIsec / 42Crunch / StackHawk — commercial enterprise platforms with continuous API testing, policy enforcement and CI/CD integration.
• mitmproxy — CLI/TUI proxy for intercepting mobile app traffic; essentially indispensable when mapping APIs of mobile clients.
• kiterunner — fast brute-forcing of API endpoints with a built-in 700k+ pattern wordlist derived from public Swagger/OpenAPI specs.
• arjun — hidden HTTP parameter discovery (some APIs accept undocumented parameters such as debug=1, admin=true).
• ffuf — general-purpose endpoint, parameter and header fuzzer; among the fastest in its class.
• sqlmap — automated SQL injection exploitation with support for JSON and REST endpoints.
• GraphQL Voyager + InQL + GraphQL Raider — GraphQL-specific tooling (introspection visualisation, automatic query building, Burp extension).
• jwt_tool + hashcat — JWT manipulation and attacks (alg confusion, key confusion, weak secret cracking).
• Frida — runtime instrumentation of mobile applications, used to bypass certificate pinning and hook functions when mapping mobile clients’ APIs.
• grpcurl and SoapUI — coverage for gRPC and SOAP endpoints respectively; often required for enterprise audits.

REST vs GraphQL vs gRPC vs SOAP pentest — differences

Each of the four major API styles has its own specifics and tends to require a different approach.

Aspect	REST	GraphQL	gRPC	SOAP
Typical vulnerabilities	BOLA, broken auth, mass assignment, IDOR	Nested query DoS, introspection leak, batching attack	TLS misconfiguration, missing method auth, deserialisation	XXE, WS-Security flaws, XPath/XSLT injection
Discovery requirements	Swagger/OpenAPI, traffic mapping	Introspection query, schema enumeration	.proto files, gRPC reflection (if enabled)	WSDL files, UDDI
Specific attacks	Parameter pollution, ID enumeration, race conditions	Query depth attacks, alias batching, query duplication	Method enumeration without .proto, weak TLS	SOAPAction header manipulation, SAML assertion forgery
Primary tools	Burp, Postman, ffuf, kiterunner	GraphQL Voyager, InQL, GraphQL Raider, BatchQL	grpcurl, gRPC Web Tools	SoapUI, WSDigger, Burp WSDL
Testing difficulty	Low to medium	High (query diversity)	High (binary protocol)	Medium (legacy stack)
Frequency in prod 2026	Very high	High (rising)	Medium (microservices)	Low (legacy enterprise)

In practice, a modern application often combines styles — REST for the public API, GraphQL (commonly Apollo Server) for an internal BFF (Backend-for-Frontend) and gRPC for inter-microservice communication. A full audit should cover each layer with the appropriate tooling.

Typical attack scenarios

Below are seven of the most common attack scenarios observed in real-world API audits.

1. BOLA via incrementing IDs

The classic case. The endpoint /api/orders/{id} returns orders. The tester logs in as User A, calls GET /api/orders/100 (their own order), then tries GET /api/orders/99, /api/orders/101 — if other users’ orders appear, the vulnerability is confirmed. UUID variant: if the application uses UUID v4, BOLA requires finding valid IDs belonging to other users (e.g. from error messages, search endpoints, predictable UUID v1).

2. Mass assignment via overposting

The endpoint PUT /api/users/me accepts JSON. The pentester adds the field isAdmin: true or accountBalance: 999999 to the request body. If the backend does not use an explicit allow-list of fields (DTO), the fields are persisted to the database. Detection: add unexpected fields to every PUT/POST endpoint and check whether they are persisted.

3. JWT manipulation

The most common variants: (a) alg none — change alg: HS256 to alg: none and strip the signature (works against libraries without strict validation), (b) algorithm confusion — swap RS256 for HS256 with the public key used as the secret, (c) weak secret — bruteforce the JWT secret with hashcat (jwt_tool simplifies this), (d) kid injection — manipulate the kid header to load an arbitrary key file.

4. Broken auth via password spray

A login API without rate limiting. The attacker tries one popular password (Password123!, Welcome2026) against thousands of usernames — minimising per-account lockout. Detection: monitoring logins by IP and behavioural anomalies. Mitigation: rate limits per IP, geolocation, MFA enforcement.

5. GraphQL introspection attack

The first thing to check in a GraphQL pentest: is the introspection query ({ __schema { types { name } } }) enabled in production? If so, the attacker receives the full schema — every type, field and mutation. Mitigation: disable introspection in production (introspection: false in Apollo Server).

6. Rate limit bypass via GraphQL batching

GraphQL supports batching — multiple queries in a single HTTP request. The attacker performs 1000× login in one request (each with a different password) and bypasses per-request rate limiting. Mitigation: rate-limit per operation rather than per request and cap batch size.

7. IDOR via API parameter

A BOLA variant via a parameter rather than a path. The endpoint GET /api/notifications?user_id={id} or POST /api/transfer { from_account: X, to_account: Y } — the pentester swaps user_id or from_account to another user’s value. Mitigation: NEVER accept user_id from the request — derive it from the authenticated JWT/session.

Compliance and regulatory requirements for API pentesting

An API pentest is often a REQUIREMENT under compliance frameworks, not merely a nice-to-have.

• PCI DSS Req 6.6 — applications handling payment card data must have a penetration test (manual or via WAF) at least annually and after every significant change. PCI DSS 4.0 (in force since 2024) is stricter still and requires targeted risk analysis for each API endpoint.
• NIS2 Art. 21 — the European Union requires essential and important entities to perform regular security testing, including APIs at a scale proportional to risk. Transposition deadline was 17 October 2024.
• DORA Art. 25 — the Digital Operational Resilience Act for EU financial entities requires regular Threat-Led Penetration Testing (TLPT) at least every 3 years for critical financial entities, typically including APIs. Applicable since 17 January 2025.
• HIPAA Security Rule § 164.308(a)(8) — periodic technical evaluation for US healthcare entities. In practice, an annual pentest for entities processing PHI through APIs.
• ISO/IEC 27001:2022 A.8.29 — testing in development and acceptance. Certification audits often check evidence of application pentests.
• GDPR Art. 32 — appropriate technical and organisational measures; a pentest is among the strongest pieces of due diligence evidence in the event of a breach.
• ENISA Guidelines on API Security 2024 — guidance from the European Union Agency for Cybersecurity recommending the OWASP API Top 10 as a baseline.

In practice, large B2B SaaS vendors operating in the EU typically need to cover NIS2, ISO 27001 and GDPR at a minimum. Banks add DORA and sometimes PCI DSS. Healthcare entities add HIPAA if they operate in the US.

How nFlo conducts API pentests

At nFlo we usually deliver API audits as part of a broader penetration testing package matched to the client’s architecture. A standard engagement covers:

• Pre-engagement workshop (1-2h) — agreement on scope, roles, documentation and the critical business flows to prioritise.
• API discovery from available Swagger/OpenAPI documentation plus active traffic mapping from web and mobile clients (where they exist).
• Full coverage of the OWASP API Security Top 10 (2023) — all ten categories for every endpoint.
• Manual business logic abuse testing — the most valuable phase, which automated scanners generally do NOT catch.
• Final report with CVSS scoring of every finding, business impact, proof-of-concept video/screen recordings and concrete remediation recommendations with code snippets.
• Retest after fixes (typically 30-50% of the original price) verifying that fixes work and have not introduced regressions.

Explore related services:

• Penetration testing — when the application also has a UI/HTML layer to audit alongside the API
• SOC 24/7 — real-time detection of attacks against APIs in production
• Incident Response — when you suspect your API has been compromised

Related terms

• Penetration testing — the broader category of pentests (web, API, network, mobile)
• API security testing — a related term combining pentest, DAST and SAST for APIs
• OWASP Top 10 — the classic OWASP Top 10 for web applications
• API — definition of API as a concept
• API Security — the broader concept of API security (architecture, monitoring, defence-in-depth)
• DAST — Dynamic Application Security Testing
• SAST — Static Application Security Testing
• Application security — the broader application security discipline

API Penetration Testing is now one of the most critical components of any modern organisation’s security programme. Almost every production application in 2026 relies on an API layer — SPAs, mobile apps, partner integrations, microservices, AI agents making function calls. Without a regular API pentest, exposure of customer data and the risk of fraud tend to grow exponentially with the number of endpoints. The OWASP API Security Top 10 (2023) is a minimum baseline, and manual business logic testing by an experienced pentester remains essentially irreplaceable — no automated DAST scanner will catch a race condition in a refund flow or BFLA on a hidden admin endpoint.