API Security Testing Services: OWASP API Top 10 Coverage and Retesting

An API security test is a manual penetration test of the endpoints that power your applications, partner integrations and mobile clients, measured against the OWASP API Security Top 10. It goes after the flaws that leak other people's data, broken object-level authorisation, weak authentication and abusable business logic, rather than the classic injection bugs a scanner is good at. This guide sets out what a full engagement covers phase by phase, how each OWASP API category is tested, what the report and the verified retest contain, and what the work costs.

Why APIs are tested differently from web applications

A web application test and an API test share tools and a methodology family, but the failure modes differ. Web applications fail on the categories in the OWASP Top 10: injection, misconfiguration, vulnerable components and, increasingly, broken access control. APIs fail on access control and logic first. The question an API tester spends most of the engagement on is not "can I inject into this parameter" but "can this user, with this token, reach that object", and the answer depends on the roles, tenants and workflows behind the endpoint rather than on the input handling in front of it.

That is why OWASP maintains a separate API Security Top 10, and why an API test is scoped around roles and tenants rather than pages. A test run with a single account against a multi-tenant API cannot find the flaw that matters most, because there is no second tenant to reach.

The six phases of an API security test

1. Scoping and rules of engagement (1 day). Collect the API definition and docs, provision accounts across roles and tenants, agree rate limits and testing windows, confirm the in-scope environments. Output: signed rules of engagement.
2. Reconnaissance and mapping (1 to 2 days). Enumerate endpoints, methods and parameters from documentation and captured traffic; map the roles and objects each one touches; note the authentication schemes in use. Output: endpoint and object map.
3. Authentication and authorisation testing (2 to 3 days). Test token issuance and validation; attack object-level and function-level access; attempt cross-tenant privilege escalation. Output: authorisation findings.
4. Business logic and injection (1 to 2 days). Abuse multi-step workflows out of order, test mass assignment on writable objects, probe input handling, chain valid requests into invalid outcomes. Output: business-logic and injection findings.
5. Manual exploitation and impact (1 day). Reproduce each finding with clean requests, demonstrate cross-tenant data access, map the data each flaw exposes, rank findings by real impact. Output: impact and risk assessment.
6. Reporting and verified retest (2 to 3 days). Report with reproducible requests, executive summary, walkthrough with your team, retest once fixes land. Output: final report and verified retest.

The engagement is scoped in phase 1 around three things: the number of endpoints, the number of tenants and the authentication schemes in use. Those three also set the price, which is covered below. An OpenAPI or GraphQL schema speeds phase 2 considerably, but the test can work from captured traffic and documentation where no schema exists.

OWASP API Security Top 10 coverage, category by category

The OWASP API Security Top 10 is the framework the test is measured against, and the table below shows where each category is covered in the phases above. The category names are OWASP's; the mapping is how we organise the work.

Two categories carry most of the weight in practice. Broken object-level authorisation is where a user changes an identifier in a request and receives another user's record, and in a multi-tenant product it is where one customer reads another's data. Broken function-level authorisation is where a normal user can call an administrative endpoint. Both are found by reasoning about roles and objects rather than by fuzzing, which is why phases 2 and 3 together take the largest share of the engagement.

REST, GraphQL and SOAP

Each API style has its own pitfalls and the test covers the ones that apply. REST APIs are tested endpoint by endpoint against the categories above. GraphQL adds introspection, which can expose the full schema, and nested queries, which can consume resources out of all proportion to the request; both are checked. SOAP adds parsing of XML payloads and WSDL exposure. The tools used include Burp Suite Professional, Postman, Nuclei, ffuf, mitmproxy, kiterunner for endpoint discovery, GraphQL Voyager and jwt_tool, but the findings that matter come from manual work on top of them.

Multi-tenant data separation

If the API serves more than one customer, this is the test to insist on. With accounts in two or more tenants we test whether one can read or change another's data, across every endpoint that touches a tenant-owned object. It is where object-level authorisation usually breaks, and it is the finding customers and auditors care about most, because it is the one that turns a bug into a breach notification. Provisioning those accounts is part of phase 1, and a test scoped without them is not a multi-tenant test.

What the report contains

Every finding is documented with reproducible requests: the exact call, the token used, the response received and what it exposes. Findings are rated with CVSS v4.0 and ranked by real impact rather than by scanner severity, so a medium-rated flaw that leaks another tenant's data is ranked above a high-rated one with no reachable data behind it. The report includes an executive summary for the people who will not read the requests, remediation guidance for the developers who will, and a walkthrough with your team. The methodology follows the OWASP Web Security Testing Guide, PTES and NIST SP 800-115.

The verified retest

The retest is part of the engagement, not a separate invoice. Once remediation lands, each finding is re-run with the same requests to confirm closure, and the verified retest report records which findings are closed and which remain. An attestation letter is issued on the final state, which is the document a customer's security review or an auditor asks for. A retest that is priced separately, or omitted, leaves you to verify your own fixes, which is the part of the process most likely to be skipped.

What API security testing costs

The indicative range is ₹50,000 to ₹4 lakh, retest included. The position in that range is set by the scope agreed in phase 1: how many endpoints, how many tenants and how many authentication schemes the test covers. A single REST API with one authentication scheme and two tenants sits towards the low end; a large GraphQL and REST estate with several identity providers and many tenants sits towards the high end. We confirm a fixed price once scoping is done, never before, and the penetration testing cost guide covers the drivers that apply across every test type.

Where SecureRoot fits

SecureRoot's API penetration testing is one of the seven surfaces in the VAPT practice, delivered manually against the OWASP API Security Top 10 for REST, GraphQL and SOAP, with a real emphasis on multi-tenant data separation. The deliverables are a findings report with reproducible requests, an executive summary, remediation guidance, a verified retest report and an attestation letter. The testing practice is led by Pragya Dwivedi, who holds the eWPTX certification in advanced web application penetration testing.

Frequently asked questions

What does an API security test cover?

Six phases over roughly two working weeks: scoping and rules of engagement, in which the API definition is collected and accounts are provisioned across roles and tenants; reconnaissance and mapping of every endpoint, method and parameter and the roles and objects each one touches; authentication and authorisation testing, which attacks object-level and function-level access and attempts cross-tenant escalation; business logic and injection, which abuses workflows, mass assignment and input handling; manual exploitation to prove each finding and map the data it exposes; and reporting with a verified retest. The test is measured against the OWASP API Security Top 10 and follows the OWASP Web Security Testing Guide, PTES and NIST SP 800-115. REST, GraphQL and SOAP are all covered, each for the pitfalls that apply to it.

Do you need an OpenAPI or GraphQL schema to test our API?

It helps a great deal and speeds up the mapping phase, but it is not required. Where no schema exists we work from captured traffic, by running the real client flows through a proxy, and from whatever documentation exists, and we use endpoint discovery tooling to find routes the documentation does not mention. The more complete the definition, the more thoroughly every endpoint can be covered, so if a schema can be produced before the test starts it is worth doing. The mapping phase also compares what the schema says against what the traffic shows, which is how undocumented, deprecated and shadow endpoints are found; those are the improper inventory management category of the OWASP API Top 10, and they are often the least protected endpoints in the estate.

Can you test multi-tenant data separation?

Yes, and it is the part of the test we push hardest on. With accounts provisioned in two or more tenants during scoping, we test whether one tenant can read or change another's data on every endpoint that handles a tenant-owned object, by substituting identifiers, replaying tokens across tenants and abusing workflows that cross tenant boundaries. This is where object-level authorisation most often breaks, and it is the finding that matters most to a SaaS business because it is the one that becomes a breach notification rather than a bug ticket. A test scoped with a single account cannot find it, so if a proposal does not ask for accounts in more than one tenant, it is not testing data separation.

Is the retest included in the price?

Yes. The indicative range of ₹50,000 to ₹4 lakh includes a verified retest once your team has remediated the findings. Each finding is re-run with the same reproducible requests used in the report, and the verified retest report records which are closed and which remain, with an attestation letter issued on the final state. The retest is built into the engagement because the alternative, leaving you to confirm your own fixes, is the step most likely to be skipped, and a customer's security review or an auditor will ask for evidence of closure rather than evidence of the original finding. The final price is fixed once scoping has established the number of endpoints, tenants and authentication schemes, and it does not change when the retest happens.

How is API security testing different from web application testing?

The tools overlap and the methodology family is the same, but the flaws differ. Web applications fail most often on injection, misconfiguration, vulnerable components and access control, the categories in the OWASP Top 10. APIs fail first on authorisation and business logic: whether this user with this token can reach that object, whether a normal user can call an administrative function, whether a sequence of valid requests produces an invalid outcome. OWASP maintains a separate API Security Top 10 for that reason, and an API test is scoped around roles, tenants and authentication schemes rather than around pages. Where an application has both a front end and an API, the two are usually tested together, because the API is where the front end's access controls are actually enforced, or not.

Next step

If your API serves more than one customer, or a security questionnaire is asking for API test evidence, book a 30 minute scoping call. Bring the API definition if you have one; you will leave with a written scope, a timeline and a fixed price that includes the retest.