Application Programming Interfaces (APIs) are the foundation of every modern IT system architecture today — from mobile applications, through e-commerce platforms, to complex cloud ecosystems and IoT solutions. API penetration testing, meaning a controlled and authorized attempt to identify and exploit vulnerabilities in endpoints, has become one of the most important elements of an organization’s security program. This guide discusses in detail the methodology, tools, and best practices for conducting penetration tests of programmatic interfaces, taking into account the specifics of different protocols and architectures.
What is API penetration testing and why is it so critical?
API penetration testing is a systematic process of testing the security of programmatic interfaces through simulating attacks that a real attacker could carry out. Unlike classic penetration tests of web applications, which involve interaction with the graphical interface (clicking buttons, filling out forms), API pentesting focuses on direct communication with endpoints — sending HTTP requests, manipulating headers, parameters, and request bodies, as well as analyzing server responses for data leaks and business logic errors.
The importance of API pentesting is growing for several fundamental reasons. First, the number of public and internal APIs in organizations is rapidly increasing. According to the Postman State of the API 2025 report, the average company maintains over 200 active API endpoints, and this number doubles every 18–24 months. Second, APIs operate on data — often sensitive, personal, or financial — making them an attractive target for attackers. Third, traditional protective tools, such as Web Application Firewalls (WAFs), were designed for browser traffic and often cannot effectively protect API traffic, which relies on structured data formats (JSON, XML, Protocol Buffers) and complex authorization schemes.
The key difference between an API pentest and a web application pentest is that APIs directly expose business logic. A graphical interface can hide certain functionalities — for example, the account deletion button is only visible to administrators. But the DELETE /api/users/{id} endpoint exists regardless of what the user sees in the browser. An API pentester checks whether access to this endpoint is properly controlled at the API level itself, not merely at the user interface level.
OWASP API Security Top 10 — detailed analysis of the most important threats
OWASP (Open Worldwide Application Security Project) has published a dedicated list of the most important API security threats — the OWASP API Security Top 10, whose latest edition (2023) serves as a reference point for every API pentester. Below we discuss each of the ten threat categories in detail.
API1:2023 — Broken Object Level Authorization (BOLA). This is the most common and simultaneously the most critical API vulnerability. It occurs when an API does not properly verify whether the user requesting access to a specific object (record, document, resource) has the authority to do so. Example: User A sends a request GET /api/orders/1234 and receives their order. They change the identifier to GET /api/orders/1235 and receive User B’s order. The cause is the lack of control at the object level — the API checks whether the user is logged in but does not check whether the given object belongs to them. BOLA accounts for over 40% of all vulnerabilities found in API pentests.
API2:2023 — Broken Authentication. This covers all errors in authentication mechanisms — from weak tokens, through lack of brute-force protection, to improper session management. Typical problems include: JWT tokens without signature verification (accepting the none algorithm), lack of token expiration, transmitting credentials in URL parameters instead of headers, and lack of rate limiting on login endpoints.
API3:2023 — Broken Object Property Level Authorization. This category combines the previous threats of Excessive Data Exposure and Mass Assignment. It concerns situations where an API returns more data than the client needs (e.g., a user profile endpoint also returns the password hash, national ID number, or internal token) or allows modification of object properties that the user should not have access to (e.g., changing their role from user to admin by including a role field in the PUT request).
API4:2023 — Unrestricted Resource Consumption. An API that does not limit resource usage is vulnerable to denial-of-service attacks. This concerns not only the number of requests per second but also the size of transmitted data (uploading gigabyte-sized files), query nesting depth (especially in GraphQL), number of elements per page (limit=999999 parameter), and expensive computational operations triggered by a single query.
API5:2023 — Broken Function Level Authorization. While BOLA concerns access to objects, BFLA concerns access to functions. Example: a regular user should not be able to call the POST /api/admin/users or DELETE /api/admin/logs endpoints. The vulnerability occurs when an API relies solely on hiding these endpoints (security through obscurity) instead of proper permission verification.
API6:2023 — Unrestricted Access to Sensitive Business Flows. New in the 2023 edition — concerns situations where an API allows automation of business processes in unintended ways. Examples: mass ticket purchasing by bots (scalping), automatic account creation to abuse promotions, automated comments or reviews. Protection requires mechanisms beyond traditional authorization — CAPTCHA, behavioral analysis, per-device restrictions.
API7:2023 — Server Side Request Forgery (SSRF). Occurs when an API accepts a URL from the user and makes a request to it on the server side. An attacker can force the server to communicate with internal services (e.g., http://169.254.169.254/latest/meta-data/ on AWS to read instance metadata), scan the internal network, or access resources unavailable from outside.
API8:2023 — Security Misconfiguration. A broad spectrum of configuration errors — from missing security headers (CORS, Content-Type), through enabled debug modes in production, lack of TLS, default credentials, to overly permissive CORS policies (Access-Control-Allow-Origin: *) allowing access from any domain.
API9:2023 — Improper Inventory Management. Organizations often lose control over how many APIs they actually expose. Old API versions (/api/v1/) remain active even though clients use /api/v3/. Staging and test environments have public access. Documentation does not reflect the actual state of endpoints. These “forgotten” APIs are particularly dangerous because they are usually not monitored and do not receive security updates.
API10:2023 — Unsafe Consumption of APIs. Concerns situations where our API consumes data from external APIs without proper validation. If an external API is compromised, our API may process malicious data — for example, in a supply chain attack scenario where a trusted data provider starts returning payloads with XSS or SQL injection code.
REST vs GraphQL vs gRPC — security differences and testing approaches
Each API architecture has its specifics that directly affect the attack surface and penetration testing methodology.
REST (Representational State Transfer) is the most widely used API architecture, based on resources and HTTP methods (GET, POST, PUT, DELETE). From a pentester’s perspective, REST has a relatively predictable structure — each resource has its endpoint, and naming conventions allow enumeration (if /api/users exists, /api/users/{id}, /api/users/{id}/orders, etc. probably also exist). Key areas for REST API testing include: access control at the object level (BOLA), HTTP method validation (does the endpoint accept DELETE when it should only handle GET?), query string parameter manipulation, Content-Type validation, and response header analysis for information leaks.
GraphQL presents an entirely different model — instead of many endpoints, there is usually one (/graphql), and the client defines exactly what data they want to receive using a query language. From a security perspective, GraphQL introduces unique challenges. Introspection — a mechanism allowing the client to query the API schema — can reveal the entire data structure if not disabled in production. Nested queries can lead to denial-of-service attacks: a query like { user { friends { friends { friends { name } } } } } can generate millions of database operations. Batching allows sending multiple queries in a single HTTP request, which enables bypassing rate limiting. Aliases allow multiple executions of the same query in a single request, facilitating brute-force (e.g., multiple login attempts). A GraphQL pentester must test: disabling introspection in production, depth and complexity limits for queries, access control at the resolver level (it is not enough to control access at the query/mutation level — permissions must be checked in every resolver), and injection protection (GraphQL is not immune to SQL injection if arguments go directly into database queries).
gRPC (Google Remote Procedure Call) uses Protocol Buffers (protobuf) as the serialization format and HTTP/2 as transport. The binary data format makes gRPC harder to test “manually” — Postman or curl are not sufficient. A pentester needs tools such as grpcurl, Evans, or dedicated Burp Suite plugins (e.g., gRPC-Web). Key areas for gRPC testing include: analysis of .proto files for internal structure disclosure, authentication testing (gRPC supports TLS mutual authentication, tokens in metadata), input validation (protobuf defines types but does not restrict values — a int32 age field will accept a negative value), reflection API testing (equivalent of introspection in GraphQL, allowing discovery of available services and methods), and inter-service communication testing (in microservice architecture, gRPC is often used for internal communication where authentication is sometimes omitted).
Webhooks represent a reversed communication model — instead of the client querying the server, the server sends HTTP requests to the client’s registered URL. Webhook testing includes: signature verification (does the webhook contain HMAC or another mechanism allowing the client to verify message authenticity?), replay attack protection (does the webhook contain a timestamp and nonce?), URL registration security (can an attacker register their URL to intercept data?), and SSRF protection (does the server validate the URL before sending the webhook?).
Authentication and authorization testing — OAuth 2.0, JWT, API keys
Authentication and authorization constitute the most critical area of API security, as bypassing them gives an attacker immediate access to data and functionality. An API pentester must thoroughly understand the mechanisms used in the system under test.
OAuth 2.0 and OpenID Connect. OAuth 2.0 is an authorization framework, not an authentication one — this distinction is often a source of implementation errors. The pentester checks: proper validation of the redirect_uri parameter (an open redirect allows authorization code theft), PKCE (Proof Key for Code Exchange) implementation for public clients (mobile apps, SPAs), whether the access token contains the minimum necessary permissions (principle of least privilege), refresh token security (rotation, revocation, lifetime), proper validation of the state parameter protecting against CSRF, and whether the implementation supports token revocation.
JSON Web Tokens (JWT). JWT is the most commonly used token format in APIs. The pentester tests: acceptance of the none algorithm (no signature), algorithm switching from RSA to HMAC (the attacker signs the token with the public key, and the server validates it with the same key as HMAC), lack of issuer (iss) and audience (aud) verification, claim manipulation (changing user_id, role, permissions), expiration time (exp) — do tokens expire within a reasonable time?, symmetric key brute-force (if HMAC) using tools like jwt_tool or hashcat, and JWT header injection (jku, x5u parameters allowing pointing to an external verification key).
API Keys. Although API keys are the simplest form of authentication, many organizations still make basic mistakes: transmitting keys in URLs (recorded in server logs, browser history, proxy logs), lack of key rotation, overly broad permissions (one key for everything), no IP or domain restriction, hardcoding keys in source code (GitHub, GitLab — searching for api_key, apiKey, API_KEY in public repositories).
Testing BOLA and BFLA in practice. Broken Object Level Authorization (BOLA) is tested by: identifying object identifiers in endpoints (UUID, integer, slug), executing a request with User A’s token, substituting the identifier for an object belonging to User B, verifying whether the API returned data or allowed modification. Broken Function Level Authorization (BFLA) is tested by: enumerating administrative endpoints (documentation, JavaScript, reverse engineering), attempting to call administrative functions with a regular user’s token, changing the HTTP method (e.g., from GET to DELETE) to discover unsecured operations.
Rate limiting and resource management — underestimated vulnerabilities
Rate limiting is a mechanism that restricts the number of requests a client can send to an API within a given time period. Its absence or improper implementation opens the door to many attacks.
Authentication brute-force. Without rate limiting on login, password reset, or OTP verification endpoints, an attacker can test thousands of combinations per second. The pentester checks: how many requests per minute can be sent to /api/auth/login without a block, whether the block is per IP (easily bypassed via proxy/VPN), per user account, or per session, whether after being blocked, changing the User-Agent, X-Forwarded-For header, or request parameters allows continuing the attack.
Resource enumeration. An API that does not limit the speed of queries to listing endpoints allows mass data downloading. Example: GET /api/users?page=1&limit=100 repeated automatically allows downloading the entire user database. The pentester tests: the maximum value of the limit parameter (does limit=1000000 work?), availability of data export endpoints (e.g., /api/users/export), lack of pagination (endpoint returns all records at once).
Denial-of-Service at the business logic level. Some endpoints perform expensive operations — report generation, file processing, complex database queries. The pentester identifies such endpoints and checks whether there are call limits, input data size restrictions, and timeouts. Particularly dangerous are endpoints accepting regular expressions from the user (ReDoS — Regular Expression Denial of Service) and endpoints processing XML (XXE — XML External Entity, Billion Laughs Attack).
Rate limiting bypasses. Even if rate limiting is implemented, the pentester tests typical bypass techniques: rotation of X-Forwarded-For, X-Real-IP, True-Client-IP headers, case manipulation in the path (/Api/Users vs /api/users), adding parameters (/api/users?foo=bar), changing HTTP method, using different API versions (/v1/users vs /v2/users), URL encoding (/api/%75sers), adding a trailing slash (/api/users/).
Tools for API penetration testing
An effective API pentest requires a set of tools covering traffic interception, automatic scanning, manual testing, and specialized analysis.
Burp Suite Professional remains the fundamental tool for API pentesters. Its functionality includes: intercepting and modifying API requests (Proxy), automatic vulnerability scanning (Scanner), manual testing with request history (Repeater), parametric attack automation (Intruder), API-dedicated extensions — Autorize (BOLA/BFLA testing), InQL (GraphQL), Param Miner (discovering hidden parameters), JSON Web Tokens (JWT analysis). The key advantage of Burp Suite in the API context is the ability to import OpenAPI/Swagger specifications, which automatically maps all endpoints and parameters.
OWASP ZAP (Zed Attack Proxy) is a free alternative that has significantly improved API support in recent versions. It offers: OpenAPI and GraphQL specification import, active and passive scanning, automation scripts in Python and JavaScript, CI/CD integration (ideal for pipeline testing). ZAP is particularly popular in DevSecOps environments, where automatic API scans are triggered with every deployment to a staging environment.
Postman — although originally a development tool, Postman combined with test collections becomes a powerful pentester tool. OWASP security collections allow automatic testing of endpoints against typical vulnerabilities. Environment variables enable quick switching between contexts (different users, roles, tokens). Newman (CLI runner) allows running collections in automation.
Specialized API tools: Astra Security — a platform for automated API security testing with a dashboard and reports; 42Crunch — OpenAPI specification analysis for security and automatic conformance testing; Akto — an open-source platform for continuous API security testing; Kiterunner — a tool for brute-forcing API endpoints (significantly more effective than traditional directory busting, as it tests HTTP methods and parameters typical for APIs); jwt_tool — a comprehensive tool for JWT testing (automatic vulnerability detection, key brute-force, claim manipulation); GraphQL Voyager — GraphQL schema visualization, facilitating identification of interesting types and relationships.
Reconnaissance tools: Amass — subdomain enumeration, discovering undocumented APIs; Nuclei — a vulnerability scanner with API-dedicated templates; Arjun — automatic discovery of hidden HTTP parameters; ffuf — a fast fuzzer for endpoint discovery.
API pentest methodology step by step
A professional API pentest proceeds in organized phases, each generating information necessary for the next. Below we present a comprehensive methodology used by experienced pentesting teams.
Phase 1: Reconnaissance. Goal: build a complete picture of the API attack surface. Activities include: obtaining and analyzing documentation (OpenAPI/Swagger, Postman Collections, README, changelog), endpoint enumeration — both documented and undocumented (brute-force with Kiterunner, source code analysis of frontend JavaScript, mobile traffic analysis), identifying API versions and older, potentially unsecured versions, technology fingerprinting (framework, server, database — based on headers, error messages, behavior), mapping authentication and authorization mechanisms, identifying relationships between endpoints (HATEOAS, documentation links).
Phase 2: Mapping and threat modeling. Based on Phase 1, the pentester creates: a catalog of all endpoints with HTTP methods, parameters, and required permissions, a permissions matrix (which roles have access to which endpoints), a STRIDE threat model (Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service, Elevation of Privilege) for key business flows, a test plan prioritizing endpoints by data criticality and function.
Phase 3: Active testing. Systematic testing includes: authorization tests (BOLA, BFLA) — for every endpoint and every role, authentication tests (brute-force, token manipulation, session management), input validation tests (injection — SQL, NoSQL, LDAP, OS command; XSS in data returned by the API; type confusion — sending a string instead of an integer; boundary testing — boundary values, empty, null, very long strings), business logic tests (race conditions, manipulating the order of steps in multi-step processes, modifying amounts, quantities, identifiers), configuration tests (CORS, security headers, error handling, TLS), rate limiting and resource tests.
Phase 4: Analysis and exploitation. Found vulnerabilities are: verified (Proof of Concept), assessed for criticality (CVSS), combined into attack chains (e.g., information disclosure + BOLA = full access to user data), documented with precise reproduction steps.
Phase 5: Reporting. The API pentest report contains: an Executive Summary (understandable for management), a detailed description of each vulnerability with: technical description, reproduction steps, exploitation proof (screenshot, request/response), CVSS score, remediation recommendation with code examples, a summary of the API security posture, a prioritized list of remediation actions.
Most common API vulnerabilities with specific examples
Beyond the threats described in the OWASP API Security Top 10, pentesters regularly identify vulnerabilities resulting from implementation errors specific to APIs.
SQL/NoSQL Injection in API parameters. Although this seems like a basic problem, injection still occurs in APIs — particularly in endpoints with filtering and sorting parameters. Example: GET /api/products?category=electronics' OR 1=1-- or in NoSQL: POST /api/login with body {"username": {"$gt": ""}, "password": {"$gt": ""}}. The pentester tests every parameter accepting user data, not just the obvious ones (login forms), but also sorting parameters (?sort=name;DROP TABLE users), filtering, search, and pagination parameters.
Server-Side Request Forgery (SSRF) in APIs. SSRF in APIs most commonly occurs in endpoints accepting URLs: importing data from an external source (POST /api/import?url=http://internal-service:8080/admin), URL preview generation (link preview), webhook registration, file download by URL. The pentester tests access to internal services (localhost, RFC 1918 addresses), cloud metadata (169.254.169.254 on AWS, metadata.google.internal on GCP), alternative protocols (file://, gopher://, dict://), and filter bypasses (shortened URLs, redirects, IPv6, alternative IP representations).
Mass Assignment / Excessive Data Exposure. Mass Assignment allows an attacker to modify fields they should not have access to. Example: the profile update endpoint PUT /api/users/me accepts the body {"name": "Jan", "email": "jan@example.com", "role": "admin", "balance": 999999}. If the API does not filter allowed fields, the attacker can change their role or balance. Excessive Data Exposure is the opposite situation — the API returns more data than the client needs. The user listing endpoint returns the password hash, reset token, address, phone number, even if the frontend only displays the name and avatar.
Race Conditions. APIs handling financial transactions, coupon systems, or limited resources are vulnerable to race conditions. Example: a discount coupon redemption endpoint — sending 100 parallel requests with the same code may cause the discount to be applied multiple times. The pentester tests this using the Turbo Intruder tool in Burp Suite or custom scripts with the asyncio library.
Broken Function Level Authorization (BFLA) in APIs with dynamic roles. In systems with configurable roles and permissions (RBAC, ABAC), the pentester tests not only default roles but also edge cases: a user with a role revoked during the session (does the token still work?), a user with two roles (do permissions aggregate correctly?), a user transferred between organizations (do they lose access to the previous one?).
How does nFlo support API security?
nFlo offers comprehensive API penetration testing, combining automated scanning with in-depth manual analysis conducted by experienced pentesters. Our methodology includes full coverage of the OWASP API Security Top 10, architecture-specific testing (REST, GraphQL, gRPC, WebSocket), and business logic analysis that no automated tools can detect.
As part of over 500 completed security projects, we have conducted hundreds of API pentests for organizations in the financial, e-commerce, SaaS, and public administration sectors. Our experts identify vulnerabilities that often escape standard scanners — from subtle authorization errors (BOLA/BFLA), through race conditions in transactional processes, to complex attack chains combining multiple seemingly non-critical vulnerabilities.
Every API pentest concludes with a detailed report containing not only vulnerability descriptions and CVSS scores but, above all, specific remediation recommendations with code examples and prioritization. We support development teams in the remediation process, offering technical consultations and retests confirming the effectiveness of implemented fixes. Working with over 200 clients and maintaining a 98% retention rate, we build long-term relationships based on trust and measurable results. Our team’s response time is under 15 minutes, enabling rapid reaction in case of critical discoveries during testing.
Summary
- APIs are the most frequently attacked vector — over 90% of the attack surface of modern applications consists of programmatic interfaces, and securing them requires a dedicated testing approach.
- OWASP API Security Top 10 forms the foundation of API pentest methodology — from BOLA (the most common vulnerability) to Unsafe Consumption of APIs, each category requires separate testing techniques.
- Different architectures, different threats — REST, GraphQL, and gRPC have different attack surfaces; GraphQL is particularly vulnerable to denial-of-service through nested queries, and gRPC requires specialized tools.
- Object-level authorization is a critical element — BOLA accounts for over 40% of API vulnerabilities and requires testing every endpoint with different user contexts.
- Automated tools are not enough — scanners detect configuration errors and typical vulnerabilities, but complex business logic errors, race conditions, and attack chains require the work of an experienced pentester.
- Rate limiting is not optional, it’s a necessity — its absence or improper implementation opens the door to brute-force, data enumeration, and denial-of-service.
- API pentesting should be a continuous process — in a DevSecOps environment, automated API security tests in CI/CD supplemented by periodic manual pentests constitute the optimal protection model.
Frequently Asked Questions
How does API penetration testing differ from regular penetration testing?
API penetration testing focuses on business logic, authorization, authentication, and data validation in programmatic interfaces. Unlike web application tests, it does not involve the graphical interface but directly tests API endpoints. An API pentester analyzes HTTP/gRPC requests and responses, manipulates parameters, headers, and tokens, and also tests mechanisms specific to APIs — such as BOLA, rate limiting, and data schema validation. This requires knowledge of OpenAPI specifications, JWT format, OAuth 2.0 protocols, and architectures such as GraphQL and gRPC.
How often should API penetration testing be conducted?
It is recommended to test APIs after every significant endpoint change, at least quarterly for critical APIs, and always before deploying a new API to production. In a DevSecOps environment, automated API security scans should be triggered with every deployment, and full manual pentests should be conducted quarterly or after every major release. Regulations such as NIS2 and DORA may impose additional requirements regarding testing frequency.
What tools are most commonly used for API pentesting?
The most popular tools include Burp Suite Professional (intercepting and modifying requests, automatic scanning, extensions like Autorize and InQL), OWASP ZAP (a free alternative with OpenAPI import and CI/CD integration), Postman with OWASP security test collections, and specialized scanners like Astra Security and 42Crunch. For JWT testing, jwt_tool and hashcat are used; for GraphQL — GraphQL Voyager and InQL; and for gRPC — grpcurl and Evans.
What is the OWASP API Security Top 10?
The OWASP API Security Top 10 is a list of the most critical API security risks, developed by OWASP (Open Worldwide Application Security Project). The latest edition from 2023 includes: Broken Object Level Authorization (BOLA), Broken Authentication, Broken Object Property Level Authorization, Unrestricted Resource Consumption, Broken Function Level Authorization, Unrestricted Access to Sensitive Business Flows, Server Side Request Forgery (SSRF), Security Misconfiguration, Improper Inventory Management, and Unsafe Consumption of APIs. The list serves as a reference point for every API pentester and should be included in the scope of every API penetration test.
