API Penetration Testing for REST, GraphQL & SOAP

API penetration testing is a security assessment of your REST, GraphQL, or gRPC APIs that identifies vulnerabilities in authentication, authorization (BOLA/BFLA), rate limiting, data exposure, and business logic (the attack surface that automated scanners miss).

Cybersecify provides API penetration testing across REST, GraphQL, gRPC, and SOAP API surfaces. We cover the OWASP API Security Top 10 (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, security misconfiguration, improper inventory management, unsafe consumption of APIs) and protocol-specific issues like GraphQL introspection abuse, query depth attacks, SOAP XXE, and gRPC reflection.

Yes. BOLA is OWASP API #1 and the highest-frequency critical finding we surface on SaaS APIs. Our methodology systematically tests every endpoint that accepts an ID parameter (user IDs, resource IDs, tenant IDs) for cross-user and cross-tenant access. We log in as user A, capture a request, change the ID to user B and verify the API correctly rejects the request. We test predictable ID formats (UUIDs vs sequential integers) and indirect references (slugs, email addresses, custom identifiers).

Yes. GraphQL testing covers introspection abuse (querying the schema to map the attack surface), query depth attacks (nested queries that exhaust server resources), aliasing-based rate limit bypass, field-level authorization gaps (a user authorized for a type but not all its fields), and batched query abuse. We test against schemas in production and staging, with documented or undocumented surface.

Yes. Authentication testing covers OAuth 2.0 flows (authorization code, client credentials, device flow, refresh token rotation), OAuth state parameter handling, JWT signature verification, JWT algorithm confusion (alg=none, RS256→HS256), JWT expiry and replay, API key rotation, key entropy, and per-endpoint authentication bypass.

API pentest is one scope. Cybersecify pricing: Startup Pentest INR 74,999 (single API scope, 7 calendar days, audit-acceptable report, 6 consulting hours, 1 free retest). Growth Pentest INR 1,79,999 (2 scopes typically web app + API, 10 days, SOC 2 + ISO 27001 audit prep, 12 consulting hours, 1 free retest).

Single API scope: 7 calendar days from kick-off to report. Two-scope engagement (typically API + web app): 10 calendar days. The report includes findings, reproduction steps, business impact, CVSS v3.1 scoring, and remediation guidance. Retest after fixes takes 1-3 business days.

Yes. Reports follow PTES (Penetration Testing Execution Standard) and OWASP API Security Top 10 (2023), produce technical + executive summaries with reproduction steps, business impact, CVSS v3.1, and remediation. The Growth Pentest plan adds explicit SOC 2 Trust Services Criteria + ISO 27001 Annex A control mapping per finding. Reports have been accepted by SOC 2 Type 1, SOC 2 Type 2, and ISO 27001 auditors.

Yes. We test rate limits on every endpoint that accepts user input (login, search, file upload, expensive aggregations, GraphQL nested queries), not just the login form. We document per-endpoint throughput, identify denial-of-service candidates, and test for resource exhaustion via parameter manipulation (large pagination limits, unbounded query depth, file size, JSON nesting depth).

BOLA (Broken Object Level Authorization) and IDOR (Insecure Direct Object Reference) describe the same root cause from different angles. IDOR is the older OWASP term for any reference (URL parameter, form field, hidden input) that points directly to an internal object without an authorization check. BOLA is the OWASP API Top 10 (2023) term and is API-specific. In modern API pentests we use BOLA because almost every BOLA finding is on a JSON endpoint with an object ID in the path or body. Testing is identical: enumerate every endpoint that takes an ID, log in as user A, swap to user B IDs, verify the API rejects. The fix is identical: server-side authorization check on every object lookup, never trust the ID from the client. We surface BOLA on roughly 60% of SaaS API engagements.

Yes. JWT algorithm confusion is a high-severity API finding we test on every engagement that uses JWT for authentication or session management. Specific tests: alg=none (token forged with no signature, library accepts it), RS256 to HS256 confusion (server using public key as HMAC secret because library does not pin the algorithm), kid header injection (manipulating the key-ID claim to point at a file or SQL value the server controls), JWK header injection (embedding an attacker-controlled public key in the token), expired-token replay, and signature stripping. We use jwt_tool and manual Burp Repeater. Findings include reproduction with the exact forged token and the library-version-specific fix.

GraphQL introspection lets a client query the schema itself (every type, field, argument, mutation). On unprotected APIs this hands the attack surface map directly to the attacker. We test whether introspection is disabled in production (it should be), whether disabling it actually works (some servers accept __schema queries even with introspection flag off), and whether the schema leaks through error messages or field suggestions. Separately we test query depth and complexity: nested queries that fan out across relationships can exhaust server memory in seconds. We submit progressively deeper queries (5, 10, 20, 50 levels), measure response time degradation, and document the resource ceiling. Fix is a depth limiter (graphql-depth-limit) plus a complexity calculator (graphql-validation-complexity) at the resolver layer.

API rate-limit testing in our engagements is methodology-driven, not a single test. We cover per-IP limits (can an attacker bypass by rotating IPs from a residential proxy pool), per-user limits (can a low-rep user hit the same endpoint as a high-rep user), per-endpoint limits (login is rate-limited but search is not, attacker uses search for credential timing), bypass via header manipulation (X-Forwarded-For, X-Real-IP, alternative HTTP verbs), GraphQL alias-based bypass (querying the same field 100 times in one request as field aliases), and burst vs sustained limits (allow 100 rps for 1 sec then 5 rps after). Every API endpoint is tested, not just login. The finding includes the exact request to reproduce and a per-endpoint recommendation (token bucket vs sliding window vs leaky bucket).