API Penetration Testing
API Penetration Testing Services for REST, GraphQL & OAuth
Most API vulnerabilities aren't found by scanners. Broken object-level authorization, JWT forgery, and mass assignment flaws require manual exploitation across authenticated sessions, the kind of work automated tools consistently miss.
Pentest Testing Corp delivers manual-led API penetration testing covering the full OWASP API Security Top 10, with findings mapped to developer-ready remediation steps. Our engagements are led by certified API Security for PCI Compliance and Ethical Hacker professionals with hands-on experience across SaaS, fintech, and healthcare API environments.
What We Test: Endpoints, Auth Flows & Authorization Logic
We test REST and GraphQL APIs across all authenticated roles and unauthenticated attack surfaces. Scope is defined by endpoint count, authorization depth, and integration complexity, not by a fixed checklist.
Auth & Tokens
Authentication & Token Security
JWT signature validation, algorithm confusion attacks (RS256 → HS256 downgrade), and token expiry enforcement. OAuth 2.0 authorization code flow abuse, implicit flow weaknesses, state parameter bypass, and refresh token misuse. Session tokens that survive logout, role changes, or password resets.
BOLA & BFLA
Authorization Flaws: BOLA & BFLA
Broken Object Level Authorization (BOLA): Can User A access, modify, or delete User B's records by substituting object identifiers in API calls? We test this across every resource type, orders, invoices, documents, user profiles. Broken Function Level Authorization (BFLA): Can a standard user invoke admin-only endpoints, trigger batch operations, or call destructive functions the UI doesn't expose? We enumerate every HTTP method and undocumented path.
Mass Assignment
Mass Assignment & Parameter Tampering
Identifying writable fields that should be read-only: is_admin, account_balance, role, plan_tier. Fuzzing JSON body parameters with Burp Suite to uncover fields the API accepts but documentation doesn't mention.
Rate Limits
Rate Limiting & Abuse Controls
Rate-limit bypass via IP rotation, header spoofing (X-Forwarded-For, X-Real-IP), and request fragmentation. OTP brute force windows, credential stuffing exposure, and unauthenticated enumeration loops on account discovery endpoints.
SSRF & Injection
SSRF via API Calls & Injection
Server-Side Request Forgery through webhook registration URLs, image import fields, and metadata fetch endpoints. SSRF probing to internal cloud metadata services (AWS IMDSv1, GCP metadata server, Azure IMDS) to test for IAM credential exposure. NoSQL injection, SQL injection via API query parameters, and command injection through file-upload or processing endpoints.
GraphQL
GraphQL-Specific Testing
Introspection abuse and schema enumeration in production environments. Query depth attacks and batching abuse that circumvent per-request rate limits. Authorization gaps in nested resolvers and mutations that don't inherit top-level auth checks. Endpoints returning full object payloads when only partial data is required, a common API3:2023 finding that leaks PII at scale.
Real-World Attack Scenarios We Simulate
These reflect actual vulnerability patterns found across live SaaS, fintech, and healthcare API engagements, not hypothetical test cases.
Scenario 1 — BOLA Leading to Cross-Tenant Data Access
An attacker registers an account, intercepts a GET /api/v1/users/{id}/documents request, and increments the id value. If authorization checks only validate that a token is present, not that the token owns the requested object, the API returns another tenant's documents. We've found this in multi-tenant SaaS platforms where object-level checks were applied inconsistently across endpoints. See how this appeared in a real engagement →
Scenario 2 — JWT Algorithm Confusion
APIs that accept both RS256 and HS256 tokens are vulnerable to a well-documented attack: take the RSA public key, use it as the HMAC secret, and sign a forged token. If the API's validation library uses the algorithm field from the token header rather than enforcing it server-side, the forged token passes. We verify this using Burp Suite's JWT Editor extension and custom Postman payloads.
Scenario 3 — SSRF via Webhook to Internal Cloud Metadata
A webhook registration endpoint accepts a user-supplied callback URL with no egress filtering. We point it at http://169.254.169.254/latest/meta-data/iam/security-credentials/ and retrieve temporary AWS IAM credentials in the response body. This surfaces regularly in payment notification services, import tools, and third-party integration endpoints.
Scenario 4 — Mass Assignment on Subscription Upgrade
A PATCH /profile/update endpoint accepts an arbitrary JSON body. We add "plan": "enterprise" and "is_verified": true to a standard account request. If the ORM doesn't explicitly whitelist accepted fields, the database writes them. We've used this to self-upgrade accounts on billing APIs, no payment required.
How We Conduct the Test
Every phase is documented and auditor-ready. Nothing enters the report until a human tester has manually confirmed it.
Step 01
Endpoint Discovery & Scope Definition
We begin with endpoint discovery using imported Postman collections, OpenAPI/Swagger specs, and passive traffic analysis through Burp Suite's proxy. Authentication flows are mapped across every defined user role before active testing starts.
Step 02
Manual Exploitation — OWASP API Top 10
Manual testing follows OWASP API Security Top 10 sequentially, with additional attack chaining to identify multi-step exploitation paths that single-check tools miss. Every finding is reproduced, CVSS-scored by exploitability and business impact, and documented with a verbatim proof-of-concept request/response pair.
Step 03
Reporting & Developer-Ready Remediation
Each finding includes a CVSS v3.1 severity rating, reproduction steps, a business impact statement, a fix recommendation, and compliance mapping to OWASP API Top 10, PCI DSS Requirement 11.3, and SOC 2 CC6.1 on request.
Step 04
Free Retest & Closure Evidence
Once your team has remediated the findings, we retest every critical and high-severity vulnerability at no additional charge within the agreed retest window. You receive written confirmation that the issue is closed, useful for compliance auditors, enterprise customers requiring vendor evidence, and internal sign-off processes.
Frameworks: OWASP API Security Top 10 (2023) · PTES · NIST SP 800-115 · MITRE ATT&CK
Compliance Mapping: PCI DSS, SOC 2, HIPAA & ISO 27001
API penetration testing isn't just a security best practice; for regulated industries, it's a documented requirement.
PCI DSS v4.0
Requirement 11.3.1 mandates penetration testing of all in-scope system components, including API layers that process or transmit cardholder data. Requirement 6.2.4 requires that software development practices actively prevent injection attacks, broken authentication, and authorization failures. Our reports are structured to satisfy both requirements directly.
SOC 2 Type II
CC6.1 (logical access controls) and CC7.1 (threat detection and monitoring) both benefit from documented API penetration testing evidence. SOC 2 auditors increasingly ask for proof that authorization testing, specifically BOLA coverage, has been conducted by an independent third party.
HIPAA Security Rule
APIs handling Protected Health Information (PHI) must satisfy the Security Rule's technical safeguard requirements around access control, audit logging, and integrity. An API pentest produces the third-party validation evidence that demonstrates due diligence to auditors and business associates.
ISO/IEC 27001:2022
Annex A.8.8 (management of technical vulnerabilities) and A.8.29 (security testing in development and acceptance) directly require what this engagement delivers: independent security testing of API surfaces with documented, prioritized remediation guidance.
What You Receive
Transparent, Fixed-Price Engagement Tiers
Fixed prices agreed before testing begins. No time-and-materials estimates, no scope creep surprises. Every tier includes a free retest on critical and high findings.
Starter
- Up to ~50 REST or GraphQL endpoints
- Single authenticated role tested
- OWASP API Top 10 full coverage
- BOLA, BFLA, JWT, and mass assignment testing
- Executive summary + technical findings report
- CVSS v3.1 scoring + PoC request/response pairs
- Free retest on critical & high findings
Professional
- 50–150 endpoints across REST and/or GraphQL
- Up to 4 authenticated roles tested
- Full OWASP API Top 10 + attack chaining
- OAuth 2.0 flow abuse, SSRF, rate-limit bypass
- GraphQL introspection, depth attacks, batching abuse
- PCI DSS / SOC 2 / HIPAA compliance mapping
- Burp Suite project files + Postman collection
- Free retest on all validated findings
Enterprise
- Unlimited endpoints, microservices, or API gateways
- All roles: admin, service-to-service, machine tokens
- Multi-environment (staging + production window)
- Attack-chain simulation across API + cloud layer
- Bundled web + API or cloud + API discount available
- Dedicated tester, priority scheduling
- Full evidence package for enterprise vendor reviews
- Ongoing PTaaS retainer option
All tiers include NDA on request · Secure evidence handling · Compliance-ready reporting · Production-safe testing
Frequently Asked Questions about API Penetration Testing
What's the difference between an API pentest and a web application pentest?
A web app pentest targets browser-side attack surface: XSS, CSRF, UI logic flaws, and client-side controls. An API pentest targets the backend data layer directly — authorization logic, token security, object-level access control, and how the API handles requests from any client, not just your front end. Most production breaches in the last three years have exploited API endpoints, not the browser. The two engagements are complementary but test fundamentally different attack surfaces.
Do you need access to our source code?
No. We work in black-box (credentials only) or grey-box configurations. For grey-box, which we recommend, you share your Postman collection, API documentation, and test credentials for each user role. Source code access can improve coverage for logic flaw detection, but it isn't required to conduct a thorough assessment.
How long does an API penetration test take?
A Starter engagement (defined scope, single environment, up to ~50 endpoints) typically completes in 5–8 business days. Multi-role, multi-environment, or GraphQL engagements with complex authorization structures run 10–15 days. We confirm the exact timeline during the scoping call before any work begins.
Is API penetration testing required for PCI DSS compliance?
Yes. PCI DSS v4.0 Requirement 11.3.1 explicitly requires penetration testing of all in-scope system components at the application layer. If your payment flow transmits cardholder data through an API — and nearly all modern payment integrations do — that API surface must be independently tested. Our reports are structured to provide direct evidence for this requirement.
Can you test an API that's still in development?
Yes, and earlier is better. Testing against a staging environment before production release is significantly less expensive to remediate than post-launch findings. We can work from a Postman collection and a staging URL before your API is publicly available, and we'll flag design-level issues that are trivial to fix before release and expensive to fix after.
Can you test in a production environment?
Yes, routinely, with agreed testing windows, safe testing controls, and communication protocols to minimize operational impact. All rules of engagement are documented before testing begins.
Ready to test your API before your next audit?
Send us your API collection or spec and we'll scope the engagement within one business day with a fixed-price quote.
NDA available on request · Secure evidence handling · Compliance-ready reporting · Production-safe testing