Key Findings (TL;DR)
- REST API pentests work endpoint-by-endpoint. Every URL plus verb is an independent attack surface. Findings cluster around BOLA, broken authentication, excessive data exposure, rate-limit gaps, and mass assignment.
- GraphQL pentests work query-by-query against a single /graphql endpoint. Findings cluster around introspection leaks, query depth attacks, batched-query DoS, field-level authorization bypass, and resolver-level injection.
- Webhook pentests test bidirectional flow. The receiving endpoint (signature validation, timestamp tolerance, replay protection) plus the sending logic (SSRF on outbound calls, redirect handling, destination validation) are separate surfaces.
- The OWASP API Top 10 categories apply across all three but the attack vectors and tooling differ materially. A vendor that does not distinguish REST methodology from GraphQL methodology is running scanner output rather than testing the API.
- Six findings recur across most GraphQL pentests in 2026: introspection enabled in production, missing field-level authorization, no query depth limits, no batched query limits, leaky error messages, mass-assignment via undocumented mutation fields.
- Three webhook findings recur: missing HMAC verification or non-constant-time compare, missing replay protection (no timestamp tolerance window), and SSRF on the sending side via redirect-follow on outbound callbacks.
- Multi-protocol engagements catch cross-protocol attack patterns (REST token granting unintended GraphQL access, webhook handler reaching internal REST routes, GraphQL mutation triggering SSRF-vulnerable outbound webhook) that single-protocol scoping would miss.
- Cybersecify pricing: Startup Pentest INR 74,999 fits one protocol surface. Growth Pentest INR 1,79,999 fits two protocols in 10 calendar days with SOC 2 + ISO 27001 mapping.
About Cybersecify
Cybersecify is a founder-led penetration testing firm based in Bengaluru (Bangalore), India. We pentest REST APIs, GraphQL APIs, and webhook surfaces across SaaS startups in India, Australia, EU, Hong Kong, and the US. Both co-founders are on every engagement: Rathnakara GN (M.Sc Cyber Security, OSCP, CompTIA PenTest+) leads pentest delivery, Ashok S Kamat handles consulting and compliance mapping. For the multi-protocol report structure auditors expect, see our pentest report sample.
Why REST, GraphQL, and Webhooks need different methodology
Most SaaS applications in 2026 expose three distinct API surfaces. A REST API for partner integrations and mobile clients. A GraphQL API powering the dashboard frontend and internal tooling. A webhook layer for event-driven customer integrations (Stripe-style send-on-event plus receive-from-customer for inbound triggers). The OWASP API Security Top 10 (2023, still current) covers all three at the category level. The exploitation methodology, the tooling, and the report structure diverge materially.
A pentester who applies REST methodology to GraphQL will miss the field-level authorization class entirely. A pentester who treats webhooks as just-another-REST-endpoint will miss the bidirectional threat model (the sending side is its own attack surface, not just the receiving side). A pentester who runs the same Burp scan across all three and calls it a pentest is producing scanner output, not security assessment.
This post walks through the methodology we use for each protocol surface, the tooling that fits, the findings that recur, and how the pricing maps to scope when we encounter multi-protocol engagements.
REST API pentest methodology
Endpoint enumeration is step one. Documented endpoints (from OpenAPI/Swagger, Postman collections, or developer documentation) cover the known surface. Undocumented endpoints require parallel discovery: directory brute-forcing with ffuf or feroxbuster, traffic capture from the actual application to surface client-only calls, and version-history dumpster-diving (older API versions sometimes survive on production behind /v1/ paths the documentation no longer mentions).
Authentication testing is step two. The token issuance flow (OAuth, API key, JWT, session) gets attacked at the issuance step and at the validation step. We test for token reuse across user accounts (BOLA via swapped tokens), token expiry enforcement, refresh-token rotation, JWT signature validation (HS256-to-none, algorithm confusion, key confusion), and API key rotation behaviour.
Authorization testing is step three and where most findings come from. BOLA (Broken Object Level Authorization) is the single most common API finding in 2026: we test every endpoint that takes a user-supplied object ID by attempting to substitute another user’s ID and verifying the response. BOPLA (Broken Object Property Level Authorization) is the second class: we test every endpoint that returns or accepts an object and verify whether sensitive properties (internal flags, admin fields, billing data) leak through.
Input handling is step four. SQL injection, command injection, server-side template injection, XML external entity, server-side request forgery. Each gets specific payload sets per the input type the endpoint accepts.
Business logic is step five and the hardest to automate. Price tampering on payment endpoints, race condition exploitation on inventory operations, workflow bypass on multi-step processes. These require understanding the application’s intended behaviour and probing for the gap between intent and implementation.
Rate limiting and resource consumption is step six. We verify rate limits are enforced per-token (not per-IP, which proxies bypass), verify limits exist on resource-expensive operations (PDF generation, report exports, search), and verify there is no path for unauthenticated bulk extraction.
GraphQL API pentest methodology
Schema enumeration is step one. If introspection is enabled in production (which it should not be), one introspection query reveals the entire schema: types, fields, mutations, subscriptions, deprecated fields, and field arguments. If introspection is disabled, we use Clairvoyance and custom schema-inference tooling to reconstruct the schema from response error messages and field-existence probing. Either way the goal is the same: a complete map of the queryable and mutable surface.
Authentication testing is step two. The authentication mechanism for GraphQL is usually inherited from the broader application (JWT in a header, session cookie, API key), so the test vectors overlap with REST. The distinction: GraphQL typically uses a single authentication check at the request boundary, and downstream authorization happens at the resolver layer. This makes resolver-level authorization the next testing focus.
Field-level authorization is step three and the GraphQL-specific finding category. We probe each field for whether the authentication-context-aware authorization runs at the resolver. Common bug: a User type has an internalNotes field intended for admin use, but the resolver does not check the requestor’s role, so any authenticated user querying their own User can read internalNotes. We map every type, every field, and every nested relationship and verify authorization at each.
Query depth and breadth is step four. A single GraphQL request can traverse the object graph arbitrarily deep and arbitrarily wide. We attempt depth attacks (nested query 20+ levels deep) and batch attacks (single request with 100+ operations) and verify the server applies depth limits, complexity scoring, and batch size limits. Without these, a single attacker request can trigger thousands of database queries and consume server resources.
Mutation testing is step five. Mutations are the write surface. We verify every mutation enforces field-level input validation (does the schema reject extra fields, or does it accept undocumented fields as mass-assignment?). We verify mutation outputs do not leak fields the caller is not authorized to read. We verify mutations enforce idempotency where intended (payment mutations especially) and rate limiting where appropriate.
Error handling is step six. GraphQL servers often leak schema information through error messages, even when introspection is disabled. We probe error responses for type names, field paths, internal stack traces, and database error fragments.
Webhook pentest methodology
Webhook pentests are bidirectional. The application both receives webhooks from third parties (Stripe, GitHub, SendGrid) and sends webhooks to customers (your own product notifies customer endpoints about events). Both directions are attack surfaces.
Receiving-side step one is signature validation. We verify the HMAC signature is required (not optional), verified with the correct algorithm, verified against the exact request body (not a re-serialized version), and compared in constant time (not with a == comparison that leaks via timing). A common 2026 finding: the signature header is checked for existence but not value-verified, accepting any non-empty signature.
Receiving-side step two is timestamp tolerance. The webhook payload should include a timestamp, the server should enforce a maximum age (typically 5 minutes), and replay attacks (resending a captured signed payload) should fail after the window. Missing timestamp validation enables payment replay attacks where a captured Stripe payment-success webhook is resent to credit the user account a second time.
Receiving-side step three is parser behaviour. We verify the request body is parsed exactly once and not re-parsed after signature verification. Multiple-parse vulnerabilities allow request smuggling where the signature verifies against version A of the body and the application logic operates on version B.
Sending-side step one is destination validation. The customer-configured webhook destination URL must be validated against an allowlist of customer-confirmed hosts. We attempt SSRF by configuring webhook destinations pointing to internal IPs (169.254.169.254 for cloud metadata, internal RFC1918 ranges, localhost). A common finding: the application validates the destination URL at configuration time but not at sending time, so DNS rebinding between configuration and send enables SSRF.
Sending-side step two is redirect handling. We configure a customer webhook destination that redirects (302) to an internal IP. The application should NOT follow the redirect and should fail closed. Missing redirect protection is a frequent 2026 finding because most HTTP client libraries follow redirects by default.
Sending-side step three is error and timeout behaviour. We verify outbound calls time out within bounded latency (no slow-loris from a customer endpoint stalling worker threads), verify retries are bounded, and verify error responses to the customer do not leak internal payload structure or stack traces.
Comparison table
| Dimension | REST API | GraphQL | Webhooks |
|---|---|---|---|
| Surface enumeration | Endpoint + verb pairs (documented + brute-force) | Single endpoint, schema enumeration via introspection or inference | Receive endpoints + outbound destinations |
| Authentication model | Per-request token or session | Single request boundary, resolver-level downstream | HMAC signature + timestamp |
| Authorization granularity | Per-endpoint or per-object | Per-field at resolver layer | Per-source IP (receive), per-destination URL (send) |
| DoS vectors | Volumetric, expensive endpoints | Query depth, batched queries, nested resolvers | Slow-loris on outbound, replay on inbound |
| OWASP API Top 10 hit rate | API1, API3, API5, API6, API9 dominate | API3 (field-level), API4 (resource consumption) dominate | API7 (SSRF-style), API8 (security misconfig), API10 (unsafe consumption) dominate |
| Primary tooling | Burp, Postman, ffuf, JWT_Tool | InQL, Clairvoyance, GraphQL Voyager, custom fuzzers | ngrok, webhook.site, HMAC bypass scripts, Burp Collaborator |
| Cybersecify scope size | 1 scope per app (20 to 50 endpoints typical) | 1 scope per app (30+ types typical) | 1 scope per surface (<10 webhook types typical) |
Tooling
For REST API pentests, our toolchain centres on Burp Suite Professional (intercepting proxy, repeater, intruder, Collaborator for SSRF callbacks). Postman or Bruno handle endpoint coverage replay from documentation. ffuf and feroxbuster handle directory and endpoint brute-forcing when documentation is incomplete. JWT_Tool handles JWT-specific attacks. Custom Python scripts handle business-logic exploitation that does not fit a generic tool.
For GraphQL pentests, we add InQL (Burp extension for GraphQL inspection), GraphQL Voyager (schema visualization for finding field-level authorization gaps), Clairvoyance (schema inference against introspection-disabled endpoints), and custom mutation fuzzers built per engagement based on the schema we extract.
For webhook pentests, we add ngrok or webhook.site for callback interception, custom HMAC bypass scripts (timing attacks, signature stripping, algorithm confusion), and Burp Collaborator for SSRF exploitation on the sending side.
Tooling alone does not produce findings. Every Cybersecify engagement combines automated coverage (about 30 percent of total effort) with manual exploitation (about 70 percent). Reports that lean heavily on tool output without manual exploitation are scanner output dressed up as a pentest, which we cover in detail in DAST scan vs pentest: why scanner output isn’t a security assessment.
Common findings across the three protocols
Three findings recur regardless of protocol. First, missing rate limits on resource-expensive operations: REST endpoints generating PDF reports, GraphQL queries triggering complex joins, webhook receivers performing synchronous database writes. Second, insufficient input validation on customer-supplied identifiers, leading to BOLA in REST and field-level authorization bypass in GraphQL. Third, error messages leaking internal implementation details (database error strings, stack traces, schema names) to unauthenticated clients.
Protocol-specific findings on top of these. REST: BOLA, mass assignment, JWT algorithm confusion. GraphQL: introspection enabled in production, field-level authorization bypass, query depth DoS. Webhooks: missing HMAC verification or non-constant-time compare, SSRF via redirect-follow on outbound.
Scope-to-cost mapping
| Application surface | Recommended Cybersecify plan | Why |
|---|---|---|
| REST API only (one application, 20 to 50 endpoints) | Startup Pentest INR 74,999 (1 scope, 7 days) | Single-protocol scope fits the plan |
| GraphQL API only (one application, 30+ types) | Startup Pentest INR 74,999 (1 scope, 7 days) | Single-protocol scope fits the plan |
| Webhook surface only (under 10 webhook types) | Startup Pentest INR 74,999 (1 scope, 7 days) | Single-protocol scope fits the plan |
| REST API + GraphQL on same application | Growth Pentest INR 1,79,999 (2 scopes, 10 days) | Multi-protocol joint coverage catches cross-protocol findings |
| REST API + Webhook surface | Growth Pentest INR 1,79,999 (2 scopes, 10 days) | SSRF on outbound webhook from REST mutation is a common cross-protocol finding |
| GraphQL + Webhook surface | Growth Pentest INR 1,79,999 (2 scopes, 10 days) | Field-level authorization bypass enabling outbound webhook trigger is common |
| All three protocols on same application | Growth Pentest INR 1,79,999 + 1 additional scope add-on | Full surface coverage in one engagement |
Plans include 6 (Startup) or 12 (Growth) hours of founder-led consulting usable during or after the engagement (6 or 12 month windows). Both plans include 1 free retest within 30 calendar days. Growth adds SOC 2 + ISO 27001 evidence mapping for auditor-ready findings. See the pricing page for the full plan comparison.
Pentest report structure for multi-protocol engagements
A pentest report worth paying for separates findings by protocol surface, not just by severity. Our deliverable structure for a multi-protocol engagement splits the technical findings section into three subsections:
- REST API findings: affected endpoint URL, verb, parameters, payload, evidence (curl reproduction), and impact mapped to OWASP API Top 10
- GraphQL findings: affected query or mutation, the field or resolver path, evidence (GraphQL query reproduction), and impact mapped to OWASP API Top 10
- Webhook findings: affected webhook type, direction (receive or send), evidence of the bypass or SSRF, and impact
This structure lets your engineering team route findings to the correct owner (REST team vs GraphQL team vs platform team) and lets your SOC 2 or ISO 27001 auditor verify control coverage per protocol surface. The Cybersecify pentest report sample shows the multi-protocol structure for a representative SaaS engagement.
Related reading
- API pentest vs Web app pentest: what they cover differently
- The authentication problem in API pentests
- How we pentest APIs without documentation
- API Security Testing: OWASP API Top 10 walkthrough
- How to evaluate an API pentest vendor
- DAST scan vs pentest: why scanner output isn’t a security assessment
Two ways to start
If REST + GraphQL or REST + Webhook coverage matches your SaaS architecture, the Growth Pentest at INR 1,79,999 is the right plan. Two scopes, 10 calendar days, SOC 2 + ISO 27001 evidence mapping, 12 hours of founder-led consulting, 1 free retest. If you only need one protocol surface covered, the Startup Pentest at INR 74,999 covers it in 7 days. Both plans include the founder-led delivery model: Rathnakara GN runs the technical engagement, Ashok S Kamat handles compliance and client communication.
Book a 30-minute discovery call to scope your application’s REST, GraphQL, or webhook surfaces against the right plan. No commitment.