Browse the site
Call Get a quote

What Is an API Security Test?

An API security test is a controlled attempt to break your API the way an attacker would, with written authorisation and a defined test window. It maps every endpoint, then tries to reach data that the calling user should not see. The core defects it looks for are broken object level authorisation, where changing an ID in the URL returns another tenant's record; broken function level authorisation, where a low-privilege user calls an admin endpoint; broken authentication, including missing signature validation on JWTs; and missing rate limiting, which turns your login and OTP endpoints into a brute-force and OTP-bombing tool.

Key takeaways

  • Broken object level authorisation is the most common serious API defect, and it appears whenever a record identifier can be changed in the request without a matching ownership check on the server.
  • An API penetration test with a valid user account of each role finds more than testing with anonymous access, because authorisation bugs only appear once the request is authenticated as the wrong user.
  • Mass assignment is a frequent finding: accepting a whole client-supplied object and binding it straight to the database lets a user set their own role or balance.
  • GraphQL and gRPC endpoints need their own depth, batching and field-level checks, because the query surface is larger and a single request can traverse many objects.
  • Rate limiting on login, OTP and password-reset endpoints is the control that decides whether credential stuffing and OTP bombing are a nuisance or a breach.

As of 24 October 2026: the service descriptions, prices and turnaround figures on this page are current.

What does an API security test actually test?

Six things, in order. Endpoint discovery, from the OpenAPI or Swagger definition, the client application traffic and the published documentation. Authentication, by testing missing, expired, malformed and wrongly signed tokens, and whether refresh tokens can be replayed. Authorisation, by replaying a legitimate low-privilege request against every other endpoint and role. Object access, by changing identifiers in the path, query string and body, and looking for a response that should not exist. Business logic, such as applying a coupon twice or skipping a payment step. And rate limiting, by sending a controlled burst and observing whether throttling applies per user, per IP and per account.

Which API vulnerabilities matter most in India?

The first three matter most, and they map to Indian regulatory exposure. Broken object level authorisation is a data breach under the DPDP Act, and in a multi-tenant SaaS product it means one customer's data reaching another, which is a contractual and legal problem, not just a technical one. Broken authentication on a payment or lending API is a financial fraud risk that ends up as a complaint with the bank and, for a fintech or an NBFC, with the regulator. Broken function level authorisation on an admin endpoint is a privileged operation executed by an ordinary user. A lesser concern in India is rate limiting, because OTP-based authentication with unlimited attempts is a direct route to account takeover.

How do you test an API safely without breaking production?

Test against a copy, not the live customer environment. Ask for a staging endpoint with anonymised or synthetic data, a set of test accounts at each role, and a way to reset state between runs. Agree the scope in writing: the base URLs, the endpoints in scope, the test accounts, the rate limit for your own testing traffic, and the person to call if something breaks. Ask the team to enable verbose request logging for the test window so you can see exactly which requests your tester generated. For a third-party API you do not own, get a signed authorisation first, because testing an API without permission is a legal problem in India.

The API security test checklist, what each check proves and the typical finding
CheckWhat it provesTypical finding
Endpoint enumerationYou know the full attack surfaceUndocumented legacy endpoints still live
Authentication bypassTokens are validated properlyExpired or unsigned JWT accepted
Object level authorisationOne tenant cannot read another's dataChanging an ID returns another record
Function level authorisationAdmin routes reject ordinary usersAdmin endpoint callable by a customer
Mass assignmentClient cannot set server-owned fieldsRole or balance field writable by the client
Rate limiting and throttlingBrute force and OTP bombing failNo limit on login or OTP endpoints
Business logic abuseThe workflow cannot be shortcutCoupon applied twice or payment step skipped

What are the frequently asked questions?

What is an API security test?
An API security test is a controlled attempt to break your API the way an attacker would, with written authorisation and a defined test window. It maps every endpoint, then tries to reach data that the calling user should not see. The core defects it looks for are broken object level authorisation, where changing an ID in the URL returns another tenant's record; broken function level authorisation, where a low-privilege user calls an admin endpoint; broken authentication, including missing signature validation on JWTs; and missing rate limiting, which turns your login and OTP endpoints into a brute-force and OTP-bombing tool.
Do I need test accounts for an API assessment?
Yes, at least one for each role, including a customer, a support agent and an administrator. Most authorisation defects are invisible to an anonymous tester because the request never gets past authentication, and you need real tokens to replay a legitimate request against the wrong role.
How long does an API penetration test take?
For a typical third-party or business API with a documented schema, a focused test runs about a week, which is enough to cover authentication, authorisation, object access, business logic and rate limiting. A large GraphQL or internal API estate needs longer, because the endpoint count is the driver.
Is testing our own API legally risky in India?
Not when it is your own system, but get the authorisation in writing either way, and define the test window, the accounts and the traffic limits. If a third party owns the API, obtain their written permission before testing, because unauthorised access to a computer resource is an offence under the IT Act.
Can a scanner find API vulnerabilities?
Partly. A scanner with good API support can find missing rate limits, weak TLS settings, absent security headers and inconsistent authorisation, but the serious findings, broken object level authorisation and business logic abuse, need a tester who understands the domain.

Get a straight answer on this

Send us your OpenAPI or Swagger file and we will return a scoped API security test plan with a fixed price and timeline.

Send us the details See pricing

Last reviewed: 24 October 2026. Information on this page is general guidance, not legal advice. Prices are indicative bands for a typical scope and are confirmed in a written quote before any work begins.