API security testing
We test REST, GraphQL and gRPC APIs the way a hostile client would: walking the schema, swapping object IDs between users and tenants, and pushing on tokens, mass assignment and rate limits, with a reproduction and a fix for each finding. Based in Hyderabad, testing APIs for companies across India.
- Covers
- REST, GraphQL and gRPC
- Baseline
- OWASP API Security Top 10
- Duration
- 5 to 10 working days
- Starts from
- INR 27,000 + 18% GST
Last reviewed
| Function | Admin | Customer | Guest |
|---|---|---|---|
| List invoices | Allowed, as designed | Allowed, as designed | Refused, as designed |
| Read invoice you own | Allowed, as designed | Allowed, as designed | Refused, as designed |
| Read another user's invoice | Allowed, as designed | Finding: allowed, but should be refused | Refused, as designed |
| Update profile | Allowed, as designed | Allowed, as designed | Refused, as designed |
| Export data | Allowed, as designed | Refused, as designed | Refused, as designed |
| Delete a user | Allowed, as designed | Refused, as designed | Refused, as designed |
- CustomerRead another user's invoice: allowed, but should be refused
01 / Who needs it
Who needs API security testing
To an attacker, your API is the product. It carries more authority than your front end ever uses, it is documented less and tested less, and every endpoint is a public endpoint to anyone who can read the traffic, including the ones meant only for your own app.
Requests for an API test tend to come from six kinds of team:
Running a mobile app back end
Routes behind an Android or iOS app are often treated as private because only the app calls them. The app's own traffic shows those routes to anyone who looks, and an endpoint that is "only used by the mobile app" answers a script just as readily. The app itself is the subject of mobile application penetration testing; this service tests the back end it talks to.
Serving many tenants from one API
Every request carries a tenant, and every route has to check it. One read or update endpoint that trusts the ID in the request, instead of the identity behind the token, is enough for one customer to reach another customer's records.
Publishing an API for partners
An API you document for customers and integrators is documented for attackers as well. Keys, scopes and quotas decide what each integrator may do, and each of them is a control that needs testing rather than trust.
Splitting a product into microservices
When services call one another, authorization between them is a discipline of its own: how each service proves who it is, whether mutual TLS is enforced where the design says it is, and what a service assumes about requests that arrive from a neighbor. The hosts and segments those services run on belong to network penetration testing.
Moving money through an API
Wallets, coupons, refunds and one-time tokens are business flows with money attached. Sniping a coupon, draining a wallet or racing a one-time token are flaws in the logic, not in the syntax, and only requests an engineer builds by hand find them.
Facing a security review
Enterprise questionnaires and audits often raise the question of whether the APIs behind a product were tested, not only its screens. The compliance section further down explains how an API report fits into that evidence.
The APIs we test come from these industries:
- SaaS
- Fintech
- Healthcare
- Logistics
- AgriTech
- Education
02 / What we test
Six areas of API coverage
We test an API as a hostile client: not through the screens your users see, but by sending requests directly, with every role's credentials and with none. Six areas make up the coverage, on top of the OWASP baseline.
Broken object-level authorization (BOLA / IDOR) sweeps
Object checks are tested systematically, not by sampling. For every object type your API serves, such as invoices, orders, users or files, two users in two tenants swap IDs across every endpoint that reads or modifies that type.
Broken function-level authorization across roles
Object checks ask whose record this is; function checks ask whether this role may call this route at all. A customer token sent to an admin route, a read-only key used on a write method, an internal endpoint left in the production build: each is tried for every role you give us.
JWT / OAuth / OIDC implementation review
Token handling is reviewed where the API enforces it: algorithm pinning, signature, expiry and the kid header for JWTs; state, redirect_uri and PKCE in OAuth flows; refresh token rotation; and whether multi-factor authentication holds at the API layer as well as in the interface.
Schema introspection and over-permissive GraphQL queries
GraphQL puts the whole schema behind one endpoint. We check whether introspection reveals more than it should in production, whether authorization is enforced inside each resolver rather than only at the edge, whether batched or aliased queries slip past limits that count requests, and whether a deeply nested query can tie up the server.
Rate-limit, quota and resource-exhaustion abuse
A limit that holds for one request at a time can give way under load. We test whether counters survive load-balanced workers, whether a per-IP limit stops a client that rotates addresses, and whether expensive endpoints can be called often enough to exhaust a resource.
Mass assignment, parameter tampering and injection
Endpoints that bind a JSON body straight to a database model accept whatever fields the model has. Each endpoint that takes a body is sent extra properties such as role, tenant_id or is_admin; parameters are altered, and inputs are checked for injection into queries and commands.
Baseline: the OWASP API Security Top 10. The list names the risk categories that matter most for APIs, from broken object-level authorization to the unsafe consumption of other APIs. The report carries a coverage matrix against it, so a reviewer can see which categories were tested and what each one produced.
Every engagement includes JWT validation, mass assignment testing, and either GraphQL-specific or gRPC-specific testing depending on your stack. For REST, the weight falls on per-endpoint authorization and mass assignment; GraphQL adds resolver-level authorization, introspection, batching and query-complexity checks.
An API test sends its requests straight to the API, with no browser in between. The pages, sessions and client-side script of a web front end are covered by web application penetration testing.
03 / Method
How an API test runs
An API test follows the same five phases as every BERRY9 engagement. What changes is the work inside them: each phase below shows what it means when the target is an API rather than a set of pages.
Show details for How an API test runs
Phase 1
Scope and rules of engagement
We agree in writing which APIs and versions are in scope, the environments and base URLs, the roles and their test accounts, any production windows, and which services run by third parties are off limits. The threat model starts here: which objects in your API would an attacker most want to read or change?
OutputSigned rules of engagement
Phase 2
Schema walk and endpoint enumeration
From your OpenAPI or GraphQL schema, or by enumeration when no schema exists, we build the full endpoint map and set the surface you expect beside the surface that actually answers, including old versions, debug routes and undocumented methods.
OutputEndpoint map, expected against actual
Phase 3
Authentication review and authorization sweep
Token handling comes first: JWT validation with algorithm pinning, signature, expiry and kid, OAuth flow integrity, refresh token rotation and MFA at the API layer. Then the sweep runs per object type, with users in different tenants trying to swap IDs on every endpoint that touches that type, and each role tried against each function.
OutputAuthorization matrix results
Phase 4
Business logic, abuse and chaining
Rate limits, anti-automation and business-flow abuse: sniping coupons, draining wallets, race conditions on one-time tokens. Each finding worth reporting is confirmed with a proof of concept, and where several combine into something worse, the chain is shown end to end.
OutputProofs of concept
Phase 5
Reporting
Every finding is written up with a reproduction your developers can run themselves, as curl commands or a HAR replay, together with the fix and a suggested CI gate, so the same class of bug is caught before it ships again.
OutputExecutive and engineering reports
How the five phases work across all our services is explained in the VAPT methodology.
04 / Common findings
Common findings in API tests
Four kinds of finding come up again and again in API work. None of them is exotic, and none shows up in a scan that only checks whether endpoints respond: each needs requests built by someone who knows what the API is supposed to refuse.
Show details for Common findings in API tests
| Finding | What happens | Severity | What your developers get |
|---|---|---|---|
| Broken Object-Level Authorization (BOLA) | An endpoint takes an object ID and acts on it without checking that the caller owns the object. Change the ID in the path or the body and the API returns, or changes, another user's record; a short script can then walk through every ID in turn. | VariesIt heads the OWASP API Security Top 10. | Each endpoint and object type where the ownership check is missing, with the pair of requests that proves it. |
| JWT misuse | The API accepts tokens it should refuse: algorithm confusion, where an HS256 signature is checked with the RSA public key as the secret; kid header injection; and HMAC secrets weak enough to crack offline. Most current libraries refuse alg=none, but these other mistakes are still found. | VariesA forged token is accepted as whichever account it names. | The validation step or library setting at fault, and a token that demonstrates it. |
| Mass assignment | A JSON body is mapped straight onto a database model, and the model has fields the user should never control, such as role, tenant_id or is_admin. One request with an extra property is enough to escalate privilege. | VariesPart of Broken Object Property Level Authorization in the OWASP API Security Top 10. | The endpoints that accept fields they should ignore, and the allowlist pattern that binds only what each role may write. |
| Rate-limit bypass and business-flow abuse | Counters that reset because each load-balanced worker keeps its own, per-IP limits that a pool of residential proxies walks around, and anti-automation that gives way under load. The outcome is coupons redeemed again and again, wallets drained or one-time tokens raced. | VariesRarely visible when an API is tried one request at a time. | The request pattern that defeats the limit, and where to enforce the counter so it holds across workers. |
In a real report each finding is scored with CVSS 3.1 against the data and functions behind that particular endpoint, which is why the table shows Varies rather than a fixed label.
05 / What you get
What you get from an API test
An API report has two audiences: the people who decide what to fix first, and the developers who have to reproduce each issue before they can close it. Both get a document written by an engineer rather than exported from a tool.
Show details for What you get from an API test
- An executive report that sets out what was tested, which findings matter most to the business and what closing them involves.
- An engineering report with a proof of concept for every finding: the request, the response that shows the issue, its impact and the fix.
- An endpoint coverage map with authorization-matrix tests, showing each endpoint, each role and the result of every pairing tried.
- Per-finding reproduction as curl or HAR replay, so a developer can run the exact request on their own machine and watch the issue happen.
- Suggested CI gates and contract-test recipes, so your pipeline catches the same class of bug before it ships twice.
- CVSS 3.1 severity and a remediation matrix that ties each finding to its score and its fix, in the order to schedule them.
- Coverage against the OWASP API Security Top 10, category by category.
The layout of a full report can be seen in the sample VAPT report.
Finding F-03 · API
Mass assignment on the profile endpoint lets a customer make themselves an admin
- Severity
- High
- CVSS 3.1
- 8.8
- Affected
- PATCH /api/v2/users/me
- Tested as
- Customer, tenant A
Steps to reproduce
- Sign in as a tenant A customer and update your own display name.
- Repeat the request with a role property set to admin in the JSON body; the API answers 200 and stores the new role.
- Call the admin-only user export with the same token: it now succeeds.
PATCH /api/v2/users/me HTTP/1.1
Authorization: Bearer <customer token>
Content-Type: application/json
{"display_name": "Asha", "role": "admin"}
Fix
Bind request bodies to an explicit allowlist of the fields each role may write, and set role and tenant on the server from the session, never from the request.
Example layout, not client dataCVSS 3.1 · OWASP API Security Top 10
06 / Price
What an API test costs
An API test starts from INR 27,000 + 18% GST. That is a starting price: the figure for your API is set after scoping, once the number of endpoints, roles and environments is known, and larger APIs cost more.
API security testing
Starts fromINR 27,000 + 18% GST
For an API with authentication and roles. The final price is set in a written proposal after scoping.
Request a scoping call- Endpoints. Each route and method is a place where an authorization check can be missing, so the endpoint count is the first thing we ask for. For GraphQL, count the queries, mutations and object types in the schema rather than the single URL they share.
- Roles. A customer, a support agent and an administrator are three sets of permissions, and partner keys with their own scopes add more. Every extra role multiplies the pairings the authorization sweep has to try.
- Environments. One staging environment is the simplest case. A second environment, a production window or separate regional deployments each add setup and testing time.
For how these factors compare across services, read the VAPT cost guide for India.
07 / What we need from you
What we need before testing starts
An API test can start without much paperwork, but four things make it faster and the coverage easier to check. A schema is helpful but not required: without one, we enumerate the endpoints ourselves, which takes longer and leaves you with an inventory of your own API as a side deliverable.
Show details for What we need before testing starts
What we need from you
- The API specification, such as an OpenAPI file or the GraphQL schema, if you have one.
- Test accounts for each role, with two users in two tenants so object IDs can be swapped between them.
- The environments and base URLs, with a staging or pre-production environment holding realistic data preferred over production.
- Signed rules of engagement covering scope, test windows and anything off limits.
BERRY9 works from one office, in Hyderabad. Public endpoints are tested over the internet from there; for internal APIs, you provide a VPN account or similar access during scoping, and on-site work is possible by arrangement. Teams based in the city can also read about our VAPT services in Hyderabad.
A staging or pre-production API is the preferred target, because abuse and volume tests can run at full strength there without reaching live customers. Production can be tested when it has to be: testing is designed to be safe, and the windows and stop conditions for anything that touches production are agreed in writing in advance.
08 / Turnaround and retest
Turnaround and retest
Most API tests take 5 to 10 working days. Where yours lands depends on the endpoint count, the number of roles and how much business logic sits behind the routes; a larger API or several environments take longer, and the proposal states the schedule.
Show details for Turnaround and retest
- Working days for most API tests
- 5 to 10
- Executive and engineering, written by hand
- 2 reports
The working days are counted from kickoff, and a schema in hand at kickoff saves the time enumeration would otherwise take.
Your developers can rerun the curl or HAR reproductions from the report to check a fix before asking us to confirm it.
The starting price for small scopes includes one free retest. For larger scopes, the retest terms are written into the proposal before work starts.
09 / Compliance evidence
API testing as compliance evidence
Frameworks rarely mention APIs by name, yet most of a modern product's data passes through them. An API report is evidence that the routes holding that data were tested independently; how much weight it carries is for your auditor to decide.
Show details for API testing as compliance evidence
SOC 2
SOC 2 does not require a penetration test. Its criteria ask for controls that find and manage vulnerabilities, penetration testing is one common way to show that, and your auditor decides what evidence is enough. For a SaaS product, the API is where much of the customer data is reached.
ISO 27001
Annex A of ISO/IEC 27001 includes control 8.8, the management of technical vulnerabilities. An API test, with its findings tracked to closure, gives that control something concrete to record. BERRY9 holds ISO/IEC 27001:2022 certificate 26MEQVU27 and ISO 9001:2015 certificate 26MEQVL30.
PCI DSS
An API that handles cardholder data, or is connected to the systems that do, falls within the PCI DSS scope, and requirement 11.4 of PCI DSS 4.x sets out penetration testing for that environment. We scope the test against that requirement and what your assessor expects.
DPDP Act
Under India's DPDP Act, a data fiduciary must take reasonable security safeguards to protect the personal data it handles. Where an API returns personal data, a test shows whether it returns that data only to the people entitled to see it.
A test report is evidence, not a certificate: BERRY9 does not certify or audit organizations, and whether a report satisfies a framework is decided by your auditor or assessor.
10 / Inquiry
Send us your scope and timeline
Tell us what the API does, roughly how many endpoints and roles it has, whether it is REST, GraphQL or gRPC, which environment we would test and when you need the report. From that, we propose a scope and timeline.
To talk it through first, call +91 86868 92922 or email contact@berry9.com.
11 / FAQ
Frequently asked questions
Short answers about scope, price and how testing works. For anything else, call +91 86868 92922.
How much does API penetration testing cost in Hyderabad?
An API penetration test starts from INR 27,000 + 18% GST, wherever in India your team is, because the work is done remotely from our Hyderabad office. Larger APIs cost more: the final figure depends on the number of endpoints, roles and environments in scope, and it is set in a written proposal after scoping. See the section on What an API test costs above.
How is API security testing different from web application testing?
A web application test works through the pages a browser renders, including the client-side code behind them. An API test skips the interface and sends requests to the API directly, so it reaches every endpoint, method and field the API accepts, including the ones no screen ever calls. A product with both a web front end and an API can have each tested, scoped on its own.
Do you test GraphQL APIs as well as REST?
Yes, both. REST testing concentrates on per-endpoint authorization, mass assignment and the OWASP API Security Top 10. GraphQL adds resolver-level authorization testing, introspection checks, batching attacks and query-complexity testing. gRPC services are covered as well, with gRPC-specific testing in place of the GraphQL checks.
Which authentication flows do you test?
JWT validation (algorithm pinning, signature, expiry and the kid header), OAuth flow integrity (state, redirect_uri and PKCE), refresh token rotation, OIDC sign-in, and whether multi-factor authentication is enforced at the API layer rather than only in the app. Algorithm confusion attacks on JWTs are still found in production systems.
Do you test rate limiting and API abuse?
Yes. Rate-limit, quota and resource-exhaustion abuse is one of the six coverage areas. The test checks whether counters hold across load-balanced workers, whether per-IP limits can be sidestepped by rotating addresses, whether anti-automation survives parallel requests, and whether flows such as coupons, wallets and one-time tokens can be abused. High-volume tests run in an environment and a window agreed in writing.
Can you test third-party APIs that our product depends on?
Not without the provider's permission. An API run by a payment gateway, a messaging provider or another vendor belongs to that vendor, so any vendor service that is off limits is named in the rules of engagement before testing starts. Your side of each integration is normally scoped with you: the endpoints that receive their callbacks, and how far your API trusts the data that comes back, which the OWASP API Security Top 10 lists as unsafe consumption of APIs.
What do you need from us to start an API test?
An API specification such as an OpenAPI file or a GraphQL schema if you have one, test accounts for each role (two users in two tenants make object-level testing possible), the environments and base URLs to test, and signed rules of engagement. A staging or pre-production environment with realistic data is preferred. See the section on What we need before testing starts above.
Can you test an API that has no documentation?
Yes. A schema is helpful but not required. With one, testing moves faster and the coverage can be checked against it; without one, we enumerate the endpoint surface ourselves, which takes longer but leaves you with an endpoint inventory you did not have before.
How long does an API penetration test take?
Most API tests take 5 to 10 working days. A larger API, more roles or more than one environment can take longer, and the written proposal states the schedule. See the section on Turnaround and retest above.
Can we point you at a staging environment instead of production?
Yes, and staging or pre-production with realistic data is the preferred option, because abuse and volume tests can then run without affecting live customers. Production can be tested when it has to be; the windows and stop conditions are agreed in writing before any testing that touches it.
Do you test internal APIs between microservices?
Yes. Service-to-service authorization is tested as a discipline of its own: how each service proves its identity, whether mutual TLS is enforced, and what one service trusts about requests from another. Internal APIs described as unreachable from the internet are tested too, through access agreed during scoping.
Do you help stop the same API bugs coming back?
Yes. The report includes suggested CI gates and contract-test recipes, such as authorization matrix tests and schema diff alerts, that your team can add to its pipeline so the same class of bug does not ship twice.