API Penetration Testing (REST and GraphQL): Technical Guide

An API penetration test is an offensive audit against the programming interfaces your organisation exposes to web clients, mobile apps, B2B partners or internal microservices. APIs are the heart of any modern digital product: the frontend, the mobile app and the back-office processes consume exactly the same endpoints, and attackers know it. That's why a modern pentest no longer ends at the web layer, it reaches every REST or GraphQL endpoint and checks authentication, object-level authorisation, business logic, token handling, abusive pagination and data exposure.

This guide covers what an API pentest is, how REST and GraphQL differ from an offensive perspective, the most exploited bugs under the current OWASP API Security Top 10, the methodology we apply and how it fits NIS2, DORA, ISO 27001 and PCI DSS.

What an API pentest is

An API pentest is an authorised and scoped offensive exercise against the REST, GraphQL, gRPC or SOAP endpoints an organisation exposes, whether internal or public. The goal is not to validate that endpoints "respond 200", it is to demonstrate which legitimate-looking requests let an attacker read data they shouldn't, write where they shouldn't, escalate permissions, abuse business logic or burn through the quota of a downstream service.

Unlike an automated scanner like Nuclei or a Postman security checker, a professional API pentest:

• Audits object-level authorisation on every resource, not just the login. The vast majority of critical API bugs are authorisation, not authentication.
• Chains calls to reproduce real flows. A sequence "login → query order → change address → pay" is where business logic bugs hide.
• Audits the implicit documentation: if your API exposes a Swagger / OpenAPI / GraphQL introspection, the team downloads it and covers it fully. If not, fuzzing and reverse engineering from the client take over.
• Delivers reproducible proof of concept with the exact request, the response and the script to reproduce.
• Justifies CVSS severity against business impact, not against a generic table.

Typical duration varies a lot: a simple REST API with 30 endpoints gets covered in 5-7 working days; a mature GraphQL API with introspection disabled and service federation can reach 15-20 days.

Why run an API pentest

Three numbers any CISO already knows that are making API pentesting mandatory:

1. APIs are today the main data exfiltration vector. Annual reports from IBM, Verizon DBIR and Akamai put attacks against APIs as the fastest-growing segment, with documented incidents in banking, healthcare and e-commerce that start at a poorly authorised endpoint and end in mass exfiltration.
2. APIs are invisible from outside. They have no UI, so generic WAFs and DOM-based tools don't protect you. An attacker with a well-configured Postman finds an IDOR faster than a normal user finds your "profile" button.
3. NIS2, DORA, PCI DSS v4.0 and ISO 27001:2022 already demand specific technical testing on APIs. PCI DSS 6.4.6 mandates evaluating APIs like any other exposed surface. NIS2 article 21 requires effectiveness testing of technical measures, which in practice includes API pentests for critical services.

Done well, an API pentest delivers:

• Real inventory of endpoints (including the shadow API the development team doesn't remember leaving exposed).
• Reproducible attack chains with exact HTTP requests and scripts.
• Prioritised recommendations by effort/benefit that the development team can apply.
• Auditable evidence for external auditors of NIS2, DORA, ISO 27001 or PCI DSS.

REST and GraphQL: why they get audited differently

REST and GraphQL are different architectures and each has its own bug catalogue.

REST

A REST API exposes resources (/users/123, /orders/45). Each endpoint performs a CRUD operation on a resource identified by URL. The attack surface scales with the number of endpoints and the relationships between resources.

Typical REST bugs:

• BOLA / IDOR (Broken Object Level Authorization). The endpoint /orders/45 returns order 45 even though it's not yours. Category #1 of the OWASP API Top 10 since 2019.
• Mass assignment. You pass {"role": "admin"} in the body of a POST to /users, and the API assigns it because the model doesn't filter which fields it accepts.
• Classic injection. SQL, NoSQL, command, LDAP. Still shows up in APIs with less validation discipline than the web layer.
• Broken rate limiting. Login without throttling enables mass credential stuffing.
• Data exposure. The endpoint returns more fields than the UI uses: internal tokens, other users' IDs, hashes.

GraphQL

A GraphQL API exposes a single endpoint (/graphql) that accepts arbitrary queries against a schema. Far more flexible than REST and, for the same reason, far more dangerous when not audited.

Typical GraphQL bugs:

• Introspection enabled in production. The endpoint exposes the full schema to any attacker with a GraphQL client. It's like leaving the Swagger public without auth.
• Aliases and batched queries. An attacker combines N calls into a single request, bypassing the rate limiting that counts requests, not operations.
• Query depth abuse. A nested query user → posts → comments → author → posts → comments → ... can make the resolver fire thousands of cascading SQL queries and bring down the database.
• Broken field-level authorisation. The query is legitimate but a specific field (user.email, order.creditCard) shouldn't be visible from that context. The development team applied authorisation at operation level but not at field level.
• GraphQL subscriptions without auth. Subscriptions over WebSocket usually inherit authorisation problems from the equivalent REST.

gRPC, SOAP and the rest

Modern API pentests also cover gRPC (common in internal microservices) and legacy SOAP (banking, public administrations, EDI integrations). They share the same principle: any interface exposing data requires object-level and field-level authorisation, regardless of protocol.

OWASP API Security Top 10: the 10 categories any auditor covers

The OWASP API Security Top 10 is the de facto standard. The current version lists:

1. API1: Broken Object Level Authorization (BOLA). The category causing the most impact. An endpoint processes an ID and returns the resource without validating that the authenticated user can see it.
2. API2: Broken Authentication. Weak tokens, JWT with alg: none accepted, passwords in query string, refresh tokens without expiry.
3. API3: Broken Object Property Level Authorization. Field-level variant: the user can read the order but shouldn't see order.internal_notes.
4. API4: Unrestricted Resource Consumption. No rate limiting, no maximum body size, no protection against batch queries in GraphQL.
5. API5: Broken Function Level Authorization. A regular user can invoke /admin/deleteUser because the role allowlist is misapplied.
6. API6: Unrestricted Access to Sensitive Business Flows. The API lets you run "buy ticket" without captcha or anti-bot, so automated bots grab them all.
7. API7: Server Side Request Forgery (SSRF). The API accepts a URL as input and fires it from the server, opening access to internal resources (cloud metadata, database, admin panel).
8. API8: Security Misconfiguration. Misconfigured CORS, missing security headers, errors leaking stack traces. More in what is a WAF for how a WAF can mitigate.
9. API9: Improper Inventory Management. Old v1 APIs still alive while v2 is the only documented one. Attackers find v1 quickly.
10. API10: Unsafe Consumption of APIs. Your API consumes a partner API without validating the response. A malicious response from the partner ends up executing in your logic.

A serious audit starts by mapping the 10 against every endpoint in scope.

Recurring mistakes that show up in 80% of audited APIs

Four systemic failures we see in almost any enterprise API, startup or large corporation:

• Operation-level authorisation but not object-level. The middleware checks "this user can call GET /orders/{id}", but doesn't check that the specific ID belongs to them. That's BOLA and, paradoxically, the easiest bug to exploit and the hardest to detect with a scanner.
• Client-side filters. The backend returns 200 orders and the frontend filters to show the current user's. Any attacker with DevTools sees the full JSON.
• GraphQL introspection alive in production. Lets an anonymous attacker download the full schema, map the entire API and design precise attacks without blind enumeration.
• "Internal" endpoints without auth because "they're behind the firewall". Until an SSRF or an open proxy exposes them. Defence in depth: every endpoint requires auth, regardless of where it lives.

Methodology: how a serious API pentest is executed

The process we follow in any API audit always follows the same six blocks:

1. Scope and authorisations. List of endpoints in scope, time windows, stop criteria (any production impact triggers a pause). If there's personal or financial data, NDA and test environments are agreed.
2. Reconnaissance. Import of the OpenAPI/Swagger if it exists; if not, capture from the legitimate client (web, mobile) using a proxy. For GraphQL, attempt introspection and fall back to searching queries in the client.
3. Authorisation mapping. Each endpoint is tested with three actor types: anonymous, user without permissions, user with permissions. Expected response vs real response matrices yield most of the critical findings.
4. Exploitation. We chain relevant flaws until we demonstrate real impact (data access, escalation, modification). No destruction, no interruption.
5. Reporting. Reproducible attack chains with exact HTTP requests, CVSS severity justified by business impact, prioritised recommendations and mitigation code when applicable.
6. Hand-off and retest. Session with development to clarify findings, support during remediation and verification of closure after fixes.

Common tooling: Burp Suite or Caido as primary proxy, Postman or Insomnia for collections, InQL and GraphQL Voyager for introspection and mapping, Nuclei for repeatable checks after the manual audit, ffuf for enumeration of hidden endpoints.

API pentest and compliance: NIS2, DORA, ISO 27001, PCI DSS

API pentesting is the technical piece that evidences several mandatory controls:

• NIS2 (article 21). Risk management measures require regular effectiveness testing. For services whose main backend is APIs, the API pentest is the relevant test. More in NIS2 in Spain: a compliance guide for 2026.
• DORA (articles 25 and 26). The TIBER-EU/TLPT regime presupposes technical testing on any infrastructure critical to financial operations, including public and private APIs. More in DORA compliance guide for financial entities 2026.
• PCI DSS v4.0 (req. 6.4.6 and 11.3.1). Demands specific evaluation of APIs and custom applications after any significant change and, at minimum, annually.
• ISO 27001:2022 (control A.8.26 Application security requirements). Requires documented and verified security requirements on APIs during the development lifecycle.
• eIDAS Regulation, GDPR. Any API processing personal data or electronic signatures inherits the associated security and traceability requirements.

How to choose an API pentest provider

Five criteria that separate a PDF full of Postman security checker output from a useful pentest:

1. Demonstrated capability in BOLA / IDOR at scale. The most exploited category and the one that kills incomplete reports the most. The provider must describe how they cover object-level authorisation per endpoint, not just "review authorisation".
2. Real GraphQL experience. GraphQL demands specific knowledge (aliases, batched queries, subscriptions) that a REST-only profile doesn't have.
3. Report that serves the development team. Exact HTTP request + reproducible script + fix suggestion. Without this, the team cannot remediate.
4. Willingness to retest after remediation. An audit without closure verification has half the value.
5. Operational confidentiality. Audited APIs usually expose personal or financial data. Encrypted internal repository, NDAs, contractual deletion at closure.

Frequently asked questions about API pentesting

What's the difference between an API pentest and a web pentest?

The web pentest audits the full application: frontend (UI, JavaScript), backend (controllers) and the APIs supporting them. An API pentest focuses exclusively on the API layer, which allows greater depth per endpoint, better BOLA and field-level authorisation coverage, and auditing APIs without UI (B2B, internal microservices, partner integrations). On public APIs with a complex web client, combining both is the effective move.

Do you need OpenAPI or Swagger documentation to audit?

It helps a lot, but it's not essential. If the documentation exists, the team imports the OpenAPI/Swagger and covers every declared endpoint. If not, reverse engineering from the legitimate client is done: browser or mobile app proxy, request capture, endpoint mapping. Lack of documentation is often a finding in itself (API9: Improper Inventory Management).

How much does an API pentest cost?

Priced by days of work, depending on API size and complexity. A REST API with 30-50 endpoints gets covered in 5-7 days; a mature GraphQL API or a B2B surface with service federation runs 12-20 days. The sensible move is to ask for a concrete proposal after a 30-60 minute scoping session that maps real scope. More in penetration testing pricing in Spain.

Does the API pentest cover rate limiting issues?

Yes, it sits under API4 (Unrestricted Resource Consumption) of the OWASP API Top 10. Tested with controlled loads. The audit includes configuration recommendations (per-token quota, adaptive throttling, captcha on sensitive endpoints) without generating denial of service in production.

Is GraphQL more secure than REST?

No, just different. GraphQL has fewer endpoints (typically just one), which reduces the raw surface, but exposes more complexity per endpoint: introspection, aliases, batched queries, query depth, field-level authorisation. A poorly configured GraphQL API is often more exploitable than an equivalent REST because the attacker with open introspection knows exactly what to ask for.

When does it make sense to audit APIs?

Three critical windows: before public launch, after any significant change (new major version, new partner integration) and annually at minimum when the system processes sensitive data. PCI DSS and NIS2 impose the annual cadence; the rest should follow the product's change rhythm.

Related resources

• What is a penetration test: the pillar guide to the full discipline.
• Web application penetration testing: application-layer audit that usually accompanies API pentesting.
• Cloud penetration testing (AWS, Azure, GCP): cloud infrastructure audit where the APIs run.
• OWASP Top 10 2025 business vulnerabilities: how it relates to the OWASP API Security Top 10.
• JWT security: vulnerabilities and best practices: the authentication building block most commonly broken in API audits.

API pentesting at Secra

At Secra we run REST, GraphQL and gRPC API pentesting inside the web and mobile audit service, under the OWASP API Security Top 10 and with real focus on object-level and field-level authorisation. Every finding ships with a reproducible HTTP request, severity justified by business impact and a prioritised remediation plan. If you want a concrete proposal for your API, get in touch through contact.