API Penetration Testing

Most security tooling was built for websites. A crawler follows links, renders a page, submits a form and looks for reflected input. An API has no links to follow and no page to render. It has endpoints, parameters, tokens and a contract, and the only way to reach most of it is to already hold a valid credential. Cloudflare reported in its 2024 API security and management report that "well over half of the dynamic traffic" on its network is API traffic rather than web pages. For a modern SaaS product the API is not a side door. It is the product, and the web app is one of several clients calling it.

Four differences change how the testing has to be done:

• There is no client left to trust. A web app can hide a button. An API cannot hide an endpoint. Anything your single page app or mobile app can call, someone holding an ordinary paid account can call directly, in any order, with any values, without ever loading your interface.
• Authorization is decided per object, not per page. A web app protects a route once. An API has to make a fresh decision for every record the caller asks for. That decision is easy to omit in code, and the omission is invisible in the response until somebody tries another customer's identifier.
• Coverage is capped by inventory. A scanner tests the endpoints it is given, and it is given the specification. Older versions still running, internal routes exposed by a broad ingress rule, and the endpoint a developer shipped last sprint without updating the spec are not in that file, so they are not tested unless a person goes looking.
• The expensive bugs are semantic. Injection and misconfiguration are still worth testing and we test them, but the findings that cost money on a SaaS API are authorization, sequence and business flow bugs. A tool does not know that your refund endpoint should be unreachable before your payment endpoint, because only your team knows what the flow is supposed to be.

So our API engagements are run by people, with tooling used for coverage and speed rather than for judgement. Rathnakara GN, Co-founder and Chief Hacking Officer (OSCP, M.Sc Cyber Security), leads the testing on every engagement. Abhinay owns pentest delivery, Theertha's team runs L1 coverage during the test and owns the retest, and Ashok Kamat, Co-founder and CEO (CCIO), handles scoping, reporting and compliance mapping. Team certifications across the practice include CISSP, CEH, CREST and ISO 27001 Lead Auditor. Both founders stay hands-on throughout, which is the point of hiring a small firm rather than a platform. Most of the API work we take on is for AI-first and API-first SaaS startups, where the API is the whole product and the person hiring us is a founder, a head of engineering or a first security hire rather than a security department.

Broken Object Level Authorization is API1 in the OWASP API Security Top 10 2023, the first entry on the list. OWASP states the root cause plainly: the server "usually does not fully track the client's state, and instead, relies more on parameters like object IDs, that are sent from the client to decide which objects to access". Cloudflare, writing in March 2026, calls it "the most pervasive and difficult-to-catch threat on the OWASP API Top 10".

Here is what it looks like on a normal B2B SaaS billing API. Alice works at Acme and has a paid account.

1. List her own invoices
   GET /api/v1/invoices
   Authorization: Bearer <alice_token>
   200 OK  [ { "id": 8412, "customer": "Acme Pvt Ltd", "amount": 240000 } ]

2. Fetch one, note the identifier in the path
   GET /api/v1/invoices/8412
   Authorization: Bearer <alice_token>
   200 OK  { "id": 8412, "customer": "Acme Pvt Ltd", ... }

3. Change one digit, keep her own valid token
   GET /api/v1/invoices/8413
   Authorization: Bearer <alice_token>
   200 OK  { "id": 8413, "customer": "A DIFFERENT COMPANY", ... }

That is the entire attack. No injection, no exploit chain, no stolen credential. One changed digit while authenticated as a legitimate customer. In a report this is a Critical, because it usually generalises: if one collection is unprotected the same code pattern is normally repeated across the codebase, and an attacker with a script walks the whole range overnight.

The naive version is often already fixed by the time we arrive. These variants usually are not, and they are why the test has to be systematic rather than a spot check:

• Unguessable identifiers are not an authorization control. Moving from sequential integers to UUIDs raises the cost of guessing and changes nothing else. Other customers' identifiers still leak through search results, export files, webhook payloads, audit trails, notification emails and shared-link features. We collect identifiers from every one of those surfaces and then try them.
• Nested objects. A route like /api/v1/orders/1001/attachments/77 commonly checks that the caller owns order 1001, then loads attachment 77 by primary key. Attachment 77 from a stranger's order comes back happily under your own order number.
• Write paths. Testing that stops at GET misses the worse half. PUT, PATCH and DELETE on another tenant's object are frequently unprotected even where the read is correct.
• Property level, which OWASP tracks separately as API3 Broken Object Property Level Authorization. The object is genuinely yours, but the response carries fields you should never see (an internal risk score, another user's email address, a password reset token), or the update accepts fields you should never set (role, tenant_id, is_verified, credit_balance).
• Function level, tracked as API5 Broken Function Level Authorization. The object check passes but the operation should never have been available to this role, for example a member calling an owner-only bulk export.

How we test it: two separate tenants, and inside each tenant one account per role. Every endpoint that accepts an identifier gets the swap, in both directions, on every method, with tokens from both tenants, plus the unauthenticated and expired-token cases. A 200 that should have been a 403 or a 404 is a finding. So is a 403 that leaks whether the record exists, through a different error string or a measurable difference in response time, because that turns a blind guess into enumeration.

The fix we recommend is architectural rather than per-endpoint: authorize on the object at the data access layer, deriving tenant and user from the session or token on the server, never from a value the client sent. In practice the query reads where id = ? and tenant_id = ? with the tenant filled in server side, enforced centrally so a new endpoint inherits it by default instead of having to remember.

OWASP added API6 Unrestricted Access to Sensitive Business Flows in the 2023 edition for a category of problem where every individual request is valid and the sequence is the attack. Nothing is malformed, so nothing trips a scanner or a web application firewall.

The pattern we look for is any flow where the client is trusted to walk the steps in order, or where the cost of one request is asymmetric between you and the caller. Examples we test on most engagements:

• Calling a later step directly. Order created, payment step skipped, fulfilment endpoint called with the order identifier, order ships.
• State transitions never re-validated on the server: refund after the order is already refunded, cancel after dispatch, approve your own request by flipping a status field the interface would not have offered.
• Race conditions on anything with a balance or a single-use token. Two identical requests fired within a few milliseconds against coupon redemption, wallet withdrawal, invite acceptance or seat allocation, where the check and the write are not atomic.
• Replay of a signed webhook, a payment confirmation callback or an idempotency key that is accepted twice.
• Economic abuse of endpoints that cost you money per call, such as OTP and SMS dispatch, transactional email, enrichment lookups or model inference, where the caller pays nothing and you pay per request.
• Free-tier and quota logic: resetting a trial by re-registering, self-referral, or promoting yourself to a higher plan through a field the billing service trusts.

None of this is discoverable from a specification file. It comes from the scoping call, where we ask what a bad day looks like for your business rather than which frameworks you use, which is a large part of why that call is taken by founders rather than handed to a sales team.

API2 Broken Authentication covers the layer everything else depends on. If the token can be forged or replayed, the object level checks behind it stop mattering.

On the JSON Web Token side, the recurring findings are:

• The signature is not actually verified. The classic alg: none acceptance, algorithm confusion where a token signed RS256 is replayed as HS256, and libraries that decode rather than verify because the decode call is the shorter one.
• Claims that are never checked. Missing aud and iss validation lets a token minted for staging, or for a different internal service, authenticate against production.
• Lifetime and revocation. Access tokens valid for weeks, refresh tokens that never rotate, and logout that clears the browser but not the token. We test whether a token captured before a password change still works after it, which is the question an auditor and an incident responder both ask.
• Tokens in the wrong place. Credentials in query strings end up in proxy logs, browser history, referrer headers and your own observability stack.

Beyond JWT we test OAuth 2.0 flows (authorization code with and without PKCE, client credentials, device flow, refresh rotation, redirect URI validation and the state parameter), API key entropy, scoping and rotation, service-to-service authentication between your own microservices, which is frequently absent behind the gateway on the assumption that the network is private, and the multi-step flows where authentication most often breaks in practice: registration, password reset, email change, multi-factor enrolment and account recovery. Our post on the authentication problem in API pentests covers why the setup for this part of the test is the step that most often delays an engagement.

API4 Unrestricted Resource Consumption is where availability and cost meet security. Most teams rate-limit the login endpoint and stop there, which leaves the expensive endpoints open.

What we test:

• Every endpoint, not just login. Search, report generation, export, bulk import, file conversion, aggregation queries and anything that fans out to a third party. We measure sustained throughput per endpoint and document the ceiling we reached and the effect we observed.
• Bypass of the limit that already exists. Spoofed X-Forwarded-For and X-Real-IP headers where the limiter trusts a header rather than the connection, alternate hostnames, and a legacy version of the same route that predates the limiter.
• Cost per request rather than requests per second. One request that asks for a page size of 100000, a nested query that fans out across relations, a deeply nested JSON body, a decompression bomb, or input designed to make a regular expression backtrack.
• Limits scoped per key rather than per tenant, which lets one customer with several keys consume capacity that belongs to everyone, and sustained limits with no burst control, where a short spike still exhausts a connection pool or a worker queue.

We do not run volumetric denial of service against production. This category is tested to the point where the behaviour is demonstrated and documented, on a staging environment wherever one exists, with a stop condition agreed before testing starts.

The categories above apply to every API style, but the way you reach them differs by protocol, and so does the surface a buyer is paying us to cover.

REST. Testing follows the resource tree: method tampering (including override headers such as X-HTTP-Method-Override), path traversal in identifiers, content type confusion, versioned routes that behave differently from one another, and the difference between what the gateway routes and what the service accepts.

GraphQL. One endpoint, a very different shape of problem: introspection and schema leakage through error text, query depth and complexity, alias-based batching that repeats a mutation many times inside a single request and slips past a limiter counting requests, and field-level authorization, which is the GraphQL form of API3, where the type is permitted and one field on it is not.

gRPC and SOAP. On gRPC: server reflection left enabled in production hands over the service definition, and the interceptor that enforces authentication is often registered on most services rather than all of them. On SOAP, still common in payments, insurance and logistics integrations: XML external entity processing, WS-Security handling, and WSDL exposure documenting operations no external caller should know about.

Webhooks, in both directions. For the webhooks you send: whether the destination URL is validated, which is API7 Server Side Request Forgery when a customer can point your infrastructure at an internal address or a cloud metadata service. For the webhooks you receive: signature verification that is present but not enforced on failure, timestamp windows that allow replay, and comparison performed with a non-constant-time string check. Our methodology across these surfaces is written up in REST, GraphQL and webhook pentest methodology.

API9 Improper Inventory Management is the finding that makes the other nine harder to close, because you cannot protect an endpoint you have forgotten. In Cloudflare's 2024 API security and management report, machine learning based discovery found "30.7% more API endpoints" than customers had identified themselves, meaning close to a third of the surface was not on the list its owners were working from.

Where we find the missing surface:

• Zombie versions. /api/v1 still answering months after /api/v2 shipped, without the authorization rewrite, the rate limiter or the input validation v2 received.
• Non-production hosts on public DNS. Staging, UAT, demo and preview deployments, frequently with weaker authentication, seeded data that turns out to be a copy of production, and no monitoring.
• Operational routes. Health, metrics, framework debug consoles, queue dashboards, playground interfaces left enabled, and administrative endpoints reachable because an ingress rule is broader than intended.
• Endpoints newer than the specification, plus undocumented parameters on documented endpoints. The spec is generated at release, the endpoint shipped on Tuesday. This is the most common source of surface a scanner run against the spec will never see.

OWASP's own illustration of the data flow blindspot in this category describes a third-party integration reaching the data of 50 million users on the strength of 270,000 direct consents, which is what an unreviewed integration looks like when nobody owns the inventory. We discover surface from your specification, from captured traffic, from your client applications, from certificate transparency and DNS, and from the responses of the endpoints we already have. Findings here are usually cheap to fix and disproportionately valuable, which is why discovery runs first rather than last. If you have no current specification at all, that is a normal starting position, and we have written about how we pentest APIs without documentation.

API engagements stall on access, not on testing. The list below is what a clean kickoff looks like. You do not need all of it to get a quote, only the first three items, and the rest can be assembled during the week before testing starts.

• What the API does and who it serves. Two or three sentences. Whether it is public, partner-facing or internal, and what the worst realistic misuse would be.
• Rough endpoint count and protocol mix. REST, GraphQL, gRPC, SOAP, webhooks, and roughly how many operations. This decides scope count, and therefore price and duration.
• Environment. Staging with production-equivalent configuration is our preference. Testing against production is possible with agreed constraints, a stop condition and a named contact reachable during the window.
• A specification or a collection. OpenAPI or Swagger, a GraphQL schema, protobuf definitions, a Postman or Insomnia collection, or a HAR capture of a real session. Any one is enough, and none of them is a blocker.
• Test accounts. Two separate tenants, and one account per role inside each, typically owner, member and read-only. This is the single input that most affects finding quality, because cross-tenant and cross-role testing is not possible without it.
• How authentication works. How to obtain a token, how long it lasts, how to refresh it, and any device binding, IP allowlisting or multi-factor step that would block automated requests. Allowlist our source addresses on rate limiters and bot protection, or tell us not to, if surviving those controls is part of what you want tested.
• Data handling rules and written authorization. Anything we must not touch or delete, whether the environment can be reset, signed permission to test, and confirmation from your hosting provider where their terms require it.

Scoping is a call with both founders, not a form. We would rather tell you one scope is enough than sell you two. If you want to compare us against other vendors before that call, our own checklist is in how to evaluate an API pentest vendor.

One scope is one API surface: a coherent set of endpoints sharing an authentication model and a codebase. Your customer-facing REST API is one scope. A separate partner API on a different auth model is a second. A web application in front of the same API is also separate, because the client-side surface is tested differently. Durations are quoted in business days, Monday to Friday, with the weekend kept as a quality buffer rather than counted as testing time.

• Startup Pentest, INR 74,999. One scope, 5 business days, 6 hours of founder-led consulting usable for 6 months from kickoff, 1 free retest. A second scope is INR 44,999 and adds 5 business days. Startup caps at 2 scopes.
• Growth Pentest, INR 1,79,999. Two scopes, 10 business days, 12 hours of founder-led consulting usable for 12 months from kickoff, SOC 2 and ISO 27001 evidence mapping, real-world attack simulation, 1 free retest.
• Three or four scopes. Growth only. From the third scope onward we run scopes in parallel, up to 3 at a time, adding 5 business days per batch, so a 3 or 4 scope engagement completes in 15 business days.
• Five or more scopes. Custom scoping proposal. We will not quote that from a form.

The consulting hours are attached to the pentest rather than sold separately, so your engineers can put an architecture or remediation question to the people who did the testing inside the validity window instead of buying a second engagement. Full plan detail sits on our pricing page, and if your situation fits neither plan, tell us what you have and we will scope it.

The deliverable is the product. You can read a redacted example end to end on our sample report page before you talk to us, with no email required, because a report you have not seen is not evidence of anything.

Every API finding carries:

• The exact request and response that demonstrates it, in a form your engineer can paste into a client and reproduce, including the account and role used.
• CVSS v3.1 scoring with the vector string, so severity can be recalculated against your own environment rather than accepted on our word.
• The mapped OWASP API Security Top 10 2023 category, so findings can be cross-referenced against the OWASP source and grouped for reporting.
• Business impact in plain language, which is the part your investor or enterprise customer will actually read.
• Remediation guidance specific to your stack, with code where code is the clearest way to say it, and a note on which fixes are architectural rather than per-endpoint.

Reports serve two audiences in one document: an executive summary for the board deck, the security questionnaire and the diligence data room, and endpoint-level technical detail for the engineers doing the work. On the Growth plan, findings additionally carry SOC 2 Trust Services Criteria and ISO 27001 Annex A control mapping so the same document serves as audit-prep evidence. If you have never had to read one of these, how to read a VAPT report walks through the structure.

The retest. Every plan includes one free retest, available within one month of the v1.0 report. It takes 1 to 3 business days depending on how many findings need re-verification, and it is run by Theertha's team, who own retesting as their main line of work. We re-test each finding, mark it Fixed, Partially Fixed, Still Vulnerable or Accepted Risk, and capture a fresh proof per item so the evidence shows the fixed state rather than asserting it. The output is a v2.0 report, never a v1.1: a full document that supersedes v1.0, because the version you hand an auditor or a customer should stand on its own without the earlier file attached.

Being clear about the boundary is part of the quote, not a disclaimer added later.

• Volumetric denial of service. We demonstrate resource consumption weaknesses and document the ceiling. We do not run flooding attacks against production.
• Social engineering and phishing of your staff, unless separately scoped as a red team engagement.
• Physical access testing and anything requiring presence at your premises.
• Third-party services you do not control. Your payment provider, your identity provider and your cloud provider's own control plane are theirs to test. We test your integration with them, including how you validate what they send you.
• Full source code review. Our default is greybox: credentials, a specification and a conversation with your engineers. Source-assisted review is available under a custom scope.
• Fixing the findings. We report, advise and re-test. Implementation stays with your team, which keeps the assessment independent, and the bundled consulting hours mean you are not doing it without access to us.

One more boundary worth stating in writing. A penetration test is a time-boxed assessment by people, against a defined scope, at a point in time. It gives you an evidenced view of what a capable attacker could reach in that window and what to fix first. It is not proof that no vulnerability exists, and any vendor telling you otherwise is selling something we would not sign our name to.