How to prepare for an API penetration test

APIs now power most modern applications. Web applications, mobile apps, SaaS platforms, cloud-native products, payment flows, partner integrations, and machine-to-machine systems all rely on APIs to exchange data and enforce business rules.

That makes API security a business-critical concern. A single broken authorization check can allow one customer to access another customer’s records. A weak authentication flow can expose accounts. A poorly protected GraphQL resolver can leak sensitive data. A misconfigured gRPC service can expose internal functionality. A vulnerable webhook or third-party integration can create a new path into trusted systems.

At Blaze Information Security, we perform API penetration tests for SaaS, fintech, healthcare, and cloud-native teams preparing for compliance, customer security reviews, or product launches. For a broader context, our Annual Penetration Testing Review 2025 analyzes 660 real-world security assessments across 145 organizations, highlighting confirmed vulnerabilities found through expert-led testing rather than scanner-only results.

This article explains what API penetration testing entails, how to prepare for an API pentest, what the OWASP API Security Top 10 2023 means in practice, how REST, GraphQL, SOAP, and gRPC testing differ, and what factors affect API pentest pricing.

What is API penetration testing?

API penetration testing is a security assessment focused on finding vulnerabilities in APIs by safely simulating how attackers, malicious users, compromised accounts, or abusive third-party integrations might interact with them.

API vulnerabilities have been involved in several high-profile data breaches. In 2023, T-Mobile disclosed that an attacker abused an API to access data from approximately 37 million customer accounts. In 2022, Optus disclosed a breach affecting up to 9.8 million customers, with public reporting pointing to exposed API access as a key factor.

These incidents show why API security cannot be treated as a scanner-only exercise. APIs expose data, identity, business logic, and integrations directly. When authorization, authentication, rate limiting, inventory management, or third-party trust controls fail, the impact can be significant.

A professional API pentest usually covers:

• API endpoints, methods, parameters, and request bodies
• Authentication mechanisms such as JWT, OAuth, API keys, SSO, HMAC, and mTLS
• Authorization between users, roles, tenants, and organizations
• Object-level and property-level access controls
• Business logic abuse cases
• Input validation and injection flaws
• Rate limits and resource consumption controls
• API gateway, cloud, and integration misconfigurations
• REST, GraphQL, SOAP, gRPC, WebSocket, or mobile back-end APIs

The goal is to find weaknesses before attackers do and provide clear remediation guidance that engineering teams can act on.

API penetration testing vs API vulnerability scanning

API vulnerability scanning can help detect common issues, but it is not the same as API penetration testing.

Automated scanners are useful for finding some known patterns, misconfigurations, exposed documentation, weak headers, and certain injection flaws. They can also be useful in CI/CD pipelines.

Manual API penetration testing goes further. It evaluates how the API behaves across real users, roles, tenants, workflows, and business rules. This is where many high-impact API vulnerabilities are found.

Scanners can support API security, but they should not replace manual testing. Broken authorization, business-logic abuse, tenant-isolation failures, and unsafe integrations usually require human analysis.

When do you need an API penetration test?

An API pentest is especially valuable when an API handles sensitive data, supports business-critical workflows, or is exposed to customers, partners, mobile apps, or third-party integrations.

Common reasons to perform API penetration testing include:

• Launching a new API or major product feature
• Preparing for SOC 2, ISO 27001, PCI DSS, HIPAA, DORA, NIS 2, or a customer security review
• Exposing APIs to customers, partners, or mobile applications
• Adding GraphQL, gRPC, serverless APIs, or microservices
• Migrating from a monolith to an API-driven architecture
• Validating security before an enterprise deal
• Retesting after fixing previous API vulnerabilities

For many B2B software companies, API penetration testing is more than a security activity; it’s also sales enablement. Enterprise customers often request recent third-party penetration testing evidence before signing or expanding a contract.

OWASP API Security Top 10 2023: what changed and what we test

The OWASP API Security Top 10 2023 is the current reference point for common API security risks. It replaced several 2019 category names and introduced newer areas of focus, including sensitive business flows, SSRF, and unsafe consumption of third-party APIs.

A proper API pentest should use OWASP API Security Top 10 2023 as a minimum testing baseline, not a ceiling. Many serious API vulnerabilities also stem from business logic flaws, race conditions, cloud misconfigurations, injection flaws, cryptographic errors, and application-specific design problems that aren’t necessarily covered directly by the top 10.

REST, GraphQL, SOAP and gRPC API pentesting

Different API technologies create different attack surfaces. A modern API pentest should be tailored to the API architecture, not forced through a generic web application checklist.

REST API penetration testing

REST APIs are usually tested by reviewing endpoints, HTTP methods, request parameters, JSON bodies, object identifiers, authentication flows, authorization rules, rate limits, and API versioning.

Common REST API tests include ID manipulation, role-based access control checks, tenant isolation testing, hidden-field tampering, pagination abuse, input validation, mass-assignment testing, and legacy endpoint review.

GraphQL API penetration testing

GraphQL APIs require dedicated testing because a single endpoint can expose a large, flexible data graph. GraphQL API pentesting may include:

• Introspection and schema exposure testing
• Schema reconstruction when introspection is disabled
• Query depth and complexity testing
• Alias and batching abuse
• Field-level authorization testing
• Object-level authorization through nested queries
• Mutation abuse
• Resolver-level SSRF
• Subscription and WebSocket abuse
• Rate-limit bypass through query structure

GraphQL security testing should go beyond checking whether introspection is enabled. The bigger question is whether authorization is enforced correctly at the resolver, object, and field levels.

gRPC and protobuf penetration testing

gRPC APIs are common in microservices, internal systems, and high-performance service-to-service communication. They often use Protocol Buffers, HTTP/2, metadata headers, streaming, and sometimes mTLS.

gRPC and protobuf testing may include:

• Protobuf schema review
• Service reflection testing
• Method-level authorization checks
• Metadata-based authentication testing
• Request and response message tampering
• Streaming abuse
• Message size and resource consumption testing
• gRPC-Web gateway review
• mTLS and service-to-service trust boundary review

Internal does not mean safe. Internal APIs still need strong authentication, authorization, input validation, and monitoring.

SOAP web services penetration testing

SOAP APIs are still found in financial services, healthcare, telecom, enterprise systems, and legacy integrations.

SOAP testing may include WSDL review, XML schema validation, XML External Entity testing, SOAPAction manipulation, authorization checks across operations, XML injection, message signing review, and error handling analysis.

Preparing for an API pentest

Preparing for an API penetration test is a crucial step that ensures the test is thorough, relevant, and has good coverage of the API’s attack surface. Below are some important basic steps needed to prepare for the assessment:

Have an NDA in place

API penetration testing often involves sharing sensitive technical information, credentials, architecture details, and sample data. Before testing begins, make sure the NDA, authorization, and rules of engagement are agreed.

The rules of engagement should define approved targets, testing dates, out-of-scope systems, escalation contacts, production restrictions, and the handling of sensitive findings.

Define the API pentest scope

Before testing starts, define the scope clearly. This should include:

• APIs and environments to test
• Endpoints, operations, services, or collections in scope
• User roles and permission levels
• Authentication methods
• Sensitive workflows
• Third-party systems or integrations
• Rate-limit and denial-of-service restrictions
• Reporting and retesting expectations

Also, define what is explicitly out of scope. This may include third-party systems, critical production workflows, destructive testing, or integrations you do not own.

Provide documentation, Postman and Swagger files and sample requests

Provide the testing team with API documentation, Postman collections, Swagger or OpenAPI files, sample requests, and information about authentication methods such as API keys, OAuth, JWT, SSO, HMAC, or mTLS.

Documentation should include endpoint descriptions, supported methods, request and response examples, expected data structures, known dependencies, and any restrictions.

If your API uses encrypted requests, packed or encoded data, HMAC-signed requests, custom headers, or non-standard authentication, provide working examples before the test starts.

Make the pentest grey-box or source code-assisted

Grey-box testing is usually the best default for API penetration testing. In a grey-box pentest, the testing team receives documentation, API collections, and credentials to test real functionality with sufficient context.

For authenticated testing, provide at least two accounts per role whenever possible. This allows testers to check whether one user can access or modify another user’s data.

For a SaaS application, that might mean two owners, two admins, two standard users, and two read-only users across at least two separate tenants or organizations.

White-box or source code-assisted testing can be valuable for complex APIs, sensitive workflows, cryptographic logic, or high-assurance environments. Access to source code reduces guesswork and can reveal issues that may be difficult to identify from the outside.

Understand commonly used API penetration testing tools

In API penetration testing, a pentester typically utilizes a suite of tools to conduct their assessments effectively. Here’s a brief rundown of some of these tools:

Postman and Swagger UI

Postman and Swagger UI are popular graphical API client tools used by developers and software testers to send requests to an API and receive responses. They provide a user-friendly interface for constructing requests to be sent to API endpoints. Both tools support a variety of request methods, including GET, POST, PUT, DELETE, and others, and allow users to include headers and body data in a straightforward manner.

They also include features for writing and automating API tests and managing different testing environments. Additionally, these tools typically can generate and publish API documentation, making it easier to share APIs among teams (e.g., Postman collections).

A GraphQL client

If your API is based on GraphQL, the team will most likely use a client that facilitates interaction with applications that speak GraphQL.

As an example, Altair GraphQL Client is a feature-rich tool for working APIs written in this technology. It provides a straightforward and graphical way for developers and testers to write queries and mutations and then send them to a GraphQL endpoint.

There are many similar tools that achieve the same goal of interfacing with GraphQL APIs and can aid in pentesting.

Burp Suite Professional

Burp Suite is a comprehensive web application security testing tool. It is used for application penetration testers to perform tasks such as crawling content and functionality, analyzing and manipulating requests, automating custom attacks, and more.

In a typical manual API penetration test, a client such as Postman, Altair GraphQL or SoapUI is proxied to Burp Suite, where the actual security testing process takes place.

Kiterunner

Kiterunner is a contextual content discovery tool written by Shubham Shah and our friends from Assetnote. The tool can brute-force API endpoints in a context-aware manner (i.e., using the correct headers, HTTP methods, and so on).

It works in different ways from regular content discovery and directory brute-force tools, and its context awareness makes it suitable for penetration testing APIs and apps written in modern web frameworks.

Automated security testing tools

Automated security testing tools can provide significant benefits during an API penetration test, helping to increase speed, coverage and to find the most obvious bugs right off the bat.

Open-source automated scanners like OWASP ZAP and BBVA’s API Check are specifically designed to detect a variety of common API vulnerabilities, including those listed in the OWASP API Security Top 10. They can quickly scan REST-based APIs for injection vulnerabilities, improper error handling, misconfigurations, and more. There are numerous other commercial security scanners that also provide strong coverage for automated API security testing.

The advantage of using such tools as part of a DevSecOps pipeline is their ability to integrate with continuous integration/continuous delivery (CI/CD) systems, enabling continuous monitoring for vulnerabilities as changes are made to the API. This automation allows development teams to identify and address potential issues early in the development lifecycle, making it an essential part of a proactive application security posture.

Nevertheless, while these tools can significantly augment the API pentesting process, it’s crucial to remember that they are not a substitute for manual penetration testing. Automated scanners might miss context-specific vulnerabilities or business logic flaws that a human tester could identify. Therefore, a balanced approach that combines automated scanning with thorough manual testing is typically the most effective way to ensure comprehensive API security.

A list of resources and several tools for API security can be found in the Awesome API Security GitHub repository.

Common API vulnerabilities and risks

APIs have their own specific set of vulnerability classes. Common web application security issues, such as cross-site scripting and front-end-specific vulnerabilities, are usually less relevant or inapplicable when conducting security-focused API penetration testing. Bear in mind that they can still be relevant if the data sent to the API is consumed elsewhere in a web application.

In June 2023, the new OWASP API Security Top 10 2023 was finally published. As the name implies, it is a list of the ten most common security risks in APIs, compiled from insights and intelligence collected by numerous penetration testing companies in recent years.

Below, we will briefly discuss, drawing from our own API pentesting experience, some of the most prevalent API security issues we encounter in our pentests. Note that the list is not exhaustive; other classes of security issues affect APIs, including specific application business-logic flaws.

Access control problems – IDORs and BOLAs

Broken Object Level Authorization (BOLA) and Insecure Direct Object References (IDOR) are closely related vulnerabilities that can occur in APIs.

BOLA occurs when an API endpoint fails to adequately verify that the user making a request has the necessary permissions to access or modify the object they are requesting.

IDOR vulnerabilities are a specific type of BOLA in which the API exposes a reference (such as an ID or name) to an internal implementation object. Attackers can manipulate these exposed references to access unauthorized resources.

An example of IDOR can be found below, taken from Portswigger Academy:

Considering an application where the customer logs in and can edit his or her own account information:

https://insecure-website.com/customer_account?customer_number=132355

What happens when the customer_number is modified to another number, say 123654? If the application or API is vulnerable to an IDOR, an attacker might alter data belonging to another user simply by modifying this parameter.

Both BOLA and IDOR vulnerabilities can lead to unauthorized data exposure, data manipulation, or other impacts, depending on the nature of the object that the attacker gains access to.

Mass assignment

Mass assignment is a class of vulnerability that arises when an endpoint automatically binds client input data (such as JSON data in a request body) to model attributes. In essence, it allows users to pass parameters that can be directly assigned to model attributes.

An attacker could manipulate parameters and modify object properties they aren’t supposed to access, leading to potential unauthorized data changes. For instance, they might modify a user’s privileges, change a record’s ownership, and perform other unexpected actions.

A classic example of mass assignment comes from OWASP. In a typical user registration flow in an application, one might see the following request:

POST /addUser
...
userid=bobbytables&password=hashedpass&[email protected]

If the application is vulnerable to mass assignment, it may be possible to modify other attributes and fields in the class instantiation, potentially escalating privileges and more:

POST /addUser
...
userid=bobbytables&password=hashedpass&[email protected]&isAdmin=true

How much does an API pentest cost?

API penetration testing cost depends on scope, complexity, and testing depth. Focused API pentests commonly start from around $4,999, while larger assessments can cost more depending on the number of endpoints, roles, tenants, workflows, API types, authentication flows, and compliance requirements.

A simple REST API with clear documentation and a small number of endpoints will usually cost less than a multi-tenant SaaS API with GraphQL, gRPC, complex authorization, payment flows, third-party integrations, and compliance-driven reporting needs.

Be cautious with cheap API pentest quotes. Red flags include scanner-only testing, no role-based authorization testing, no business logic testing, no mapping to the OWASP API Security Top 10 2023, and no reproducible proof-of-concept evidence.

Final remarks

APIs are now one of the most important attack surfaces in modern software. They expose business logic, sensitive data, authentication flows, third-party integrations, and internal services that are often difficult to assess from the front end alone.

A strong API penetration test helps uncover issues that scanners often miss, including broken authorization, tenant isolation failures, exposed object properties, business logic abuse, GraphQL resolver issues, unsafe gRPC services, and risky third-party API consumption.

By testing APIs regularly and fixing the issues found, organizations can reduce security risk, improve compliance readiness, support enterprise sales, and protect customer trust.

If your organization is looking for a professional penetration testing company to improve your API security posture, contact our experts today.

FAQ