API Penetration Testing: Step-by-Step Guide for 2026

Introduction

Most SaaS breaches don’t start with a zero-day exploit or a compromised employee. They start at an exposed API endpoint, one that accepts an object ID it shouldn’t, returns fields a low-privilege user was never meant to see, or skips authentication on a single route that somebody forgot to lock down.

According to Salt Security’s 2024 State of API Security Report, 95% of organizations experienced an API security incident in the prior 12 months. Yet in the hundreds of API penetration tests Pentest Testing Corp has conducted, we routinely find critical vulnerabilities that internal teams and automated scanners missed entirely. The gap isn’t tooling, it’s methodology.

This guide documents the exact methodology certified ethical hackers use to test REST and GraphQL APIs: reconnaissance, authentication testing, authorization probing, injection testing, and business logic abuse. If you’re a CTO, DevSecOps lead, or security engineer responsible for a production API, this is the process you should be demanding from any pentest provider.

Why API Penetration Testing Is a Distinct Discipline

API security testing is not web application testing with different URLs. The attack surface, trust model, and vulnerability classes are fundamentally different, which is why a web application pentester who has not specifically worked with APIs will consistently miss high-severity findings.

The Attack Surface Has Shifted

Modern applications are API-first. A typical enterprise SaaS product exposes hundreds of internal and external API endpoints. Third-party integrations, mobile clients, and CI/CD pipelines all consume these APIs directly-often with weaker authentication than the web front-end. Attackers have noticed.

Automated Scanners Are Not Enough

DAST tools can find obvious injection points and missing security headers. They cannot identify Broken Object Level Authorization (BOLA) because that requires understanding the application’s data model-which user IDs belong to which tenant, which resource IDs are sequential versus UUIDs, and what data a given role should and should not be able to access. This is adversarial reasoning, not pattern matching.

Compliance Is Catching Up

PCI DSS 4.0, SOC 2 Type II, and ISO 27001 increasingly require evidence of manual API security testing-not just automated scanning. If you are preparing for a compliance audit or a security questionnaire from an enterprise customer, a manual API penetration test with a formal report is the expected deliverable.

Scoping an API Penetration Test

Poor scoping is the primary reason API pentests deliver low ROI. Here is what must be defined before testing begins.

Scope Inputs Required

Choosing the Right Test Type

Black-box testing mimics an external attacker with no prior knowledge. It surfaces the highest-visibility vulnerabilities but leaves coverage gaps on complex business logic.

Grey-box testing—the most common and most cost-effective configuration-provides an API specification and multiple user accounts. Testers can achieve near-complete endpoint coverage and test authorization at every privilege level.

White-box testing includes source code access. It is appropriate for high-risk components, financial systems, or when a breach has already occurred and root cause analysis is needed.

API Pentest Methodology: Step-by-Step

This is the six-phase methodology Pentest Testing Corp applies to every API security audit.

Phase 1: Reconnaissance and Endpoint Discovery

The goal of this phase is to build a complete inventory of every reachable endpoint, including undocumented ones that development teams have forgotten.

1. Collect baseline documentation. Import OpenAPI/Swagger specifications, Postman collections, and any available API changelogs into Burp Suite or a similar proxy.
2. Run passive crawling. Proxy all client-side application traffic (web, mobile, desktop) through an intercepting proxy to capture API calls made by the legitimate application.
3. Discover hidden routes. Use wordlist-based forced browsing against common API route patterns (/api/v1/, /api/v2/, /internal/, /admin/, /debug/). Tools: ffuf, feroxbuster, dirsearch.
4. Check JavaScript bundles. Frontend JavaScript frequently contains hardcoded API routes, environment variables, and occasionally API keys. Parse main.js and chunk files using LinkFinder or manual inspection.
5. Scrape public sources. GitHub repositories, Postman public workspaces, and archived Swagger UI instances often expose endpoints that have been removed from current documentation but remain live on the server.
6. Enumerate versions. Test all historical API versions (/v1/, /v2/, /v3/). Older versions are frequently left running with fewer security controls and deprecated authentication mechanisms.

Deliverable: A complete endpoint inventory with HTTP method, authentication requirement, and parameter map for every route discovered.

Phase 2: Authentication Testing

Authentication testing covers how the API verifies identity-not whether identity is correctly used to gate resources (that is authorization, covered in Phase 3).

1. Test for missing authentication. Remove the Authorization header from every request. Many APIs have route-level authentication enforcement with gaps on individual endpoints.
2. Test token validation rigor. Submit expired JWTs, JWTs signed with alg: none, JWTs with the HS256 algorithm substituted where RS256 is expected, and JWTs with modified claims.
3. Test OAuth 2.0 flows. Check for authorization code interception via open redirects, PKCE bypass, and token leakage in referrer headers or server-side logs.
4. Test API key security. Check whether API keys are transmitted in query strings (logged by every proxy and CDN), whether they are bound to an IP or scope, and what the revocation process looks like.
5. Test credential brute-force controls. Verify that account lockout, CAPTCHA, or progressive delay is enforced on login and password reset endpoints at the API layer—not only at the web UI layer.

Phase 3: Authorization Testing (BOLA, BFLA, Privilege Escalation)

Authorization vulnerabilities are the most commonly exploited and the most commonly missed. They require creating multiple test accounts at different privilege levels and systematically testing whether each account can access resources it should not.

1. Map the object model. Identify every resource type the API exposes—users, organizations, projects, invoices, reports-and document which user roles should have access to each.
2. Test BOLA (Broken Object Level Authorization) / IDOR. For every endpoint that accepts a resource identifier (numeric ID, UUID, slug), test whether substituting another user’s resource ID returns unauthorized data. This includes GETs, PUTs, DELETEs, and POSTs that reference existing objects.
3. Test BOPLA (Broken Object Property Level Authorization). Check whether mass assignment allows setting sensitive properties-is_admin, account_tier, verified-by including them in a POST or PATCH body even when the API documentation does not advertise these fields.
4. Test Broken Function Level Authorization (BFLA). Attempt to call admin-only API functions (user deletion, tenant management, billing) using low-privilege credentials.
5. Test tenant isolation. In multi-tenant SaaS applications, verify that user A in Tenant X cannot read, write, or enumerate objects belonging to Tenant Y.

Phase 4: Injection and Input Validation Testing

1. SQL injection. Fuzz all string parameters, filter operators, and sort fields for SQL injection. Use time-based payloads for blind injection scenarios.
2. NoSQL injection. For MongoDB and similar datastores, test JSON parameter injection using operators like $where, $gt, and $ne.
3. Command injection. Target file upload endpoints, report generation APIs, and any parameter that interacts with the filesystem.
4. Server-Side Request Forgery (SSRF). Test URL parameters, webhook URLs, and import-from-URL features for SSRF using an out-of-band callback server.
5. GraphQL injection. For GraphQL APIs, test for SQL injection within resolvers, NoSQL injection in filters, and SSTI in template-based field resolvers.

Phase 5: Business Logic and Rate Limiting

1. Test whether multi-step workflows (checkout, account upgrade, file sharing) can be completed out of order or with steps skipped.
2. Test whether resource quotas can be bypassed by using multiple accounts, concurrent requests, or manipulating plan identifiers.
3. Test whether operations that should be idempotent (like applying a coupon code) can be triggered multiple times via race conditions.
4. Test rate limiting consistency across all authentication states and API versions.

Phase 6: Reporting and Evidence Collection

Every finding must include: a unique identifier, CVSS score, OWASP API Security Top 10 mapping, reproduction steps, evidence (sanitized request/response), and a concrete remediation recommendation. Pentest Testing Corp also includes a developer-facing technical annex that can be used directly in sprint planning.

REST API Pentest: Key Attack Vectors

REST APIs are the dominant architectural style and the most frequently tested. These are the highest-yield attack vectors in practice.

HTTP Method Tampering

REST APIs often implement GET and POST handlers but leave PUT, DELETE, and PATCH methods unguarded. Always test all HTTP verbs against every endpoint, particularly for state-changing operations.

Parameter Pollution

HTTP parameter pollution (HPP) submits duplicate query string or body parameters to exploit inconsistencies in how frameworks parse them. ?user_id=1&user_id=2 may be parsed as either ID depending on the backend language and framework.

Mass Assignment

Modern frameworks like Rails, Django, and Laravel automatically bind request body parameters to model attributes. If the API does not use an explicit allowlist, an attacker can set any attribute on the underlying model-including role, subscription level, or verified status, simply by including it in the request body.

Excessive Data Exposure

APIs frequently return full object representations and rely on the client to display only the relevant fields. A mobile app may display only first_name but the API response contains SSN, internal_notes, password_hash, and two_factor_recovery_codes. Always log and inspect full API responses, not just what the client renders.

GraphQL Security Testing: Where Standard REST Methodology Falls Short

GraphQL requires a different testing approach. The OWASP GraphQL Cheat Sheet covers this comprehensively, but the following are the highest-impact vectors in practice.

Introspection Abuse

GraphQL’s introspection feature-enabled by default in most implementations-allows any client to query the full schema: all types, fields, queries, mutations, and subscriptions. In production environments, introspection should be disabled or restricted to authenticated administrative users. Test for it with:

{ __schema { queryType { name } } }

If introspection is disabled, attempt field suggestion attacks, which many implementations do not disable independently of introspection.

Query Depth and Complexity Attacks

GraphQL’s nested query structure enables DoS attacks through deeply recursive queries. Without query depth limits or complexity scoring, a single malformed query can exhaust server resources:

{ user { friends { friends { friends { friends { id name email } } } } } }

Test whether depth limits, complexity limits, and query timeout controls are enforced.

Batching Attacks

GraphQL supports query batching—sending multiple operations in a single HTTP request. This is legitimate functionality that attackers exploit to bypass rate limiting. A rate limiter counting HTTP requests will not detect 100 authentication attempts submitted as a single batched query.

Resolver-Level Authorization

Each GraphQL field resolver must enforce its own authorization. Unlike REST, where route-level middleware can block unauthenticated access to entire endpoint trees, GraphQL resolvers are invoked individually. Test authorization at the field level, not just at the query level.

Tooling Reference for API Security Audits

Common Findings: What We See Most

Across 250+ clients and 6,000+ validated vulnerabilities, these are the finding categories by frequency and severity:

BOLA accounts for the highest proportion of critical findings and is consistently the most business-impactful vulnerability in SaaS API audits. The root cause is nearly always the same: server-side authorization checks are implemented at the collection level but not at the individual object level.

Remediation Priorities After an API Penetration Test

Receiving a pentest report is the beginning of remediation work, not the end. Here is the triage framework we recommend.

Immediate (0–7 Days)

Address any finding with a CVSS score of 9.0 or above, particularly missing authentication on sensitive endpoints and JWT algorithm confusion vulnerabilities. These represent direct paths to account takeover or unauthorized data access.

Short-Term (1–4 Weeks)

Remediate BOLA/IDOR vulnerabilities, which typically require systematic changes to authorization middleware. Rather than fixing individual endpoints, implement object-level authorization as a reusable service or middleware layer that is called consistently across all resource access patterns.

For mass assignment vulnerabilities, replace any pattern of binding raw request bodies to model objects with explicit attribute allowlists. Every framework that supports ORM has a native mechanism for this.

Medium-Term (1–3 Months)

Address excessive data exposure by introducing API response schemas that explicitly define what each role should receive. GraphQL users should implement field-level authorization using a permissions library. REST API users should replace full-object serialization with role-scoped serializers.

Implement API security monitoring if it is not already in place. A runtime API security platform (Salt Security, Noname Security, Traceable AI) ingests traffic and detects anomalous access patterns that a quarterly pentest cannot catch in real-time.

Developer Training

Our data consistently shows that teams with no prior API security training reintroduce the same vulnerability classes within 6–12 months of remediation. A post-pentest developer workshop covering OWASP API Security Top 10 with hands-on labs significantly reduces recurrence rates.

For a complete security assessment framework, see our web application penetration testing services and cloud security review services.

Conclusion

API penetration testing is not optional for any organization running production APIs. The vulnerability classes that cause the most damaging breaches-BOLA, missing authentication, mass assignment-are systematically missed by automated scanning tools and require human adversarial testing to surface reliably.

The methodology in this guide covers the six phases Pentest Testing Corp applies to every API security audit: endpoint discovery, authentication testing, authorization probing, injection testing, business logic abuse, and evidence-based reporting. Demand this level of rigor from any provider you engage.

If you are preparing for a compliance audit, responding to a security questionnaire, or simply need confidence in the API layer powering your product, we can scope and execute a test in days.