API Security Testing

A web application test is not an API test.

OWASP ASVS 5.0.0 keeps them in separate chapters — V3 Web Frontend Security and V4 API and Web Service — and says in terms that for a machine-to-machine API the V3 requirements “will not be relevant”. A scope naming “ASVS” without naming chapters has not made the distinction.

A mobile application test is not an API test either.

OWASP’s Mobile Application Security project keeps network communication with remote endpoints in its own control group, MASVS-NETWORK, alongside storage, cryptography, platform and resilience. Testing the binary tells you about the binary.

One test account makes the largest finding class unreachable.

Object level authorisation is tested by calling an endpoint as account A with an identifier belonging to account B. With one account there is no B. The report will be silent, and silence reads as absence.

You cannot test what you have not enumerated.

The specification drifts from the deployment in both directions. §13.1.1(c) requires the scope to be derived from a consolidated and updated asset inventory, and §13.2.3(ii)(b) requires the as-of date of that inventory to appear in the report. Read the date before you read the findings.

Authentication and token handling

Who is the caller, and how long does the server keep believing it?

Object level authorisation

Can an authenticated caller read or change an object that is not theirs?

Function level authorisation

Can a caller invoke an operation their role is not supposed to have?

Mass assignment and object property level authorisation

Which fields can a caller write that the form never showed them?

Rate limiting and resource consumption

What does one caller cost you, and how many times can they do it?

Input validation

What does the server do with input the client would never have sent?

Error handling and information disclosure

What does the server tell a caller when something goes wrong?

Versioned and deprecated endpoints still serving traffic

What else is still answering on this host?

REST / JSON over HTTP

Scoping unit: The route, and the role.

The default case, and the one the rest of this page is written against. Effort scales with routes multiplied by meaningful role pairs, plus parameter count on the write endpoints.

What to watch for

Path parameters are the identifier surface. Query filters and sort fields are a second, quieter one — a filter that accepts a column name is an injection sink and an authorisation bypass at the same time.

GraphQL

Scoping unit: The resolver and the field, not the path.

One POST endpoint, potentially hundreds of resolvers, each with its own authorisation decision. Scoping it as one endpoint under-prices it by an order of magnitude. ASVS 5.0.0 gives GraphQL its own section at V4.3.

What to watch for

Introspection left enabled in production is a free specification for an attacker and a useful one for a tester — establish which it is. Query depth, breadth and aliasing turn a cheap request into an expensive one, which makes resource consumption a first-class question rather than an afterthought.

gRPC and protobuf

Scoping unit: The service method.

Binary framing, so a proxy-and-click approach produces nothing readable without the definitions. The .proto files are the specification and are the first thing to ask for.

What to watch for

Tooling has to be agreed in advance under §13.2.2(iii)–(iv), because the tester will be using something less common and it still needs the licence confirmation, the controlled test and your written approval.

WebSocket and server-sent events

Scoping unit: The message type, and the subscription.

Authorisation is decided at the handshake and then, too often, never again — so a connection established as one user keeps receiving messages after the entitlement changes. ASVS 5.0.0 covers WebSocket at V4.4.

What to watch for

Subscribe to channels the account should not see. Send message types the client never sends. A long-lived connection is a long-lived authorisation decision.

Webhooks and inbound callbacks

Scoping unit: The endpoint, and the signature scheme.

An unauthenticated write path by design, protected by a signature rather than a session. Routinely omitted from both the web scope and the API scope because nobody thinks of it as part of the application.

What to watch for

Replay without a timestamp window. Signature verification that fails open when the header is absent. Comparison that is not constant-time. And the question of what the handler does with the payload, which is an input-validation surface reachable by anyone who learns the URL.

File upload and download endpoints

Scoping unit: The endpoint, the storage path and the signed URL.

Two authorisation decisions rather than one: who may upload, and who may retrieve. Where retrieval goes through object storage with a pre-signed URL, the second decision has left your application entirely.

What to watch for

Signed URL lifetime and scope. Predictable storage keys. And whether the download endpoint re-checks entitlement or simply redirects. ASVS V5 File Handling is the chapter to name.

The API gateway or backend-for-frontend

Scoping unit: The rule set, and what it forwards.

A layer that can enforce authentication, rate limits and schema validation — or that can be bypassed entirely if any service is reachable directly. Whether it is in scope is a decision, and an unstated one usually means it was not tested.

What to watch for

Headers set by the gateway and trusted downstream. ASVS 4.1.3 requires that a header set by an intermediary — X-Real-IP, X-Forwarded-anything, X-User-ID — “cannot be overridden by the end-user”, which is a two-request test with a serious consequence.

Shadow API

An endpoint, a service or a whole host that exists in the deployment and in no specification, no asset list and no scope. Added by a team under delivery pressure, exposed by a framework default, stood up for an integration, or split out of a monolith and given its own route.

How it is found

By diffing the gateway route table and the client-derived route list against the specification. Anything in the first two and not the third is a shadow route, and the difference is a finding before any test runs.

The clause it fails

§13.1.1(c) requires the scope to be derived from the consolidated and updated asset inventory. A shadow API is, by definition, outside that inventory — so it is outside the scope the clause contemplates, and the failure is a governance failure before it is a security one.

Zombie API

An older version, a retired endpoint or a decommissioned host that still resolves and still answers, usually against the same production database, usually predating the authorisation fixes applied to the current version. Nothing calls it. Everything can reach it.

How it is found

By enumerating versions and hosts rather than routes — /v1 alongside /v3, beta and staging hostnames in certificate transparency logs, DNS entries pointing at a live load balancer. Then by asking which of them share a datastore with production.

The clause it fails

§13.2.3(ii)(b) requires the auditee to state the date up to which the scope and asset inventory have been updated, and requires that date in the report. A zombie is what the gap between that date and today contains.

An intercepting proxy, for client-derived discovery

Sits between each client and the API and records what the current build actually calls, with the parameters it sends and the headers it sets. This is how the client-derived route list in the discovery table above is produced. Its limit is the same as the client’s: it sees what the client calls and nothing else, which is why it is one input to the inventory rather than the inventory.

A specification-driven request generator, for parameter and method coverage

Takes the OpenAPI document, the GraphQL schema or the .proto definitions and generates requests across parameters, types, methods and boundary values. Good at the input-validation and message-structure classes, but bounded by the specification, so it inherits every drift the reconciliation pass found. This is the class that needs the most care on write endpoints — a misconfigured fuzzer against a write endpoint is a data-integrity incident, not a test result.

A scripted harness, for the authorisation matrix

The fourteen tests above, run as a loop over every route and every role pair, comparing each response against the control case. This class does not exist as a product, and that is the substantive point rather than a complaint about the market: the loop has to be written against your identifiers, your roles and your tenancy model. No scanner knows which identifier belongs to which tenant, so no scanner can distinguish a correct denial from a missing check. Expect this to be bespoke work and expect it to appear in the man-hours as such.

Comprehensive Cyber Security Audit Policy Guidelines, v1.0, 25 July 2025

The instrument’s own words

Application security testing (including web applications, mobile applications and APIs).

One of the twenty-six classes of engagement the document covers — a list §6 itself opens as “including, but not limited to”. APIs are named inside the class rather than left to be inferred from “application”.

Comprehensive Cyber Security Audit Policy Guidelines, v1.0, 25 July 2025

The instrument’s own words

The type of audit must be communicated before commencement — “VAPT …, EAPT …, DLA …, Configuration Audit, Process Audit, Mobile Application Security Audit, Web Application Security Audit, API Security Audit, Compliance audit etc.”

An API Security Audit is a declarable type in its own right. Declare it. The nine named types end with “etc.”, so the list is open, but the declaration is not optional.

Comprehensive Cyber Security Audit Policy Guidelines, v1.0, 25 July 2025

The instrument’s own words

The scope of audits “should include audit of entire cyber infrastructure including system, applications (both Web/Mobile), software, network infrastructure, Operational Technology (OT) / Industrial Control Systems (ICS) environment, cloud architecture, Application Programming Interfaces (APIs), database and hosting infrastructure, code review, application security, data Security, testing of Incident response capability of the auditee.”

APIs are named in the scoping clause as well as in the engagement class. A scope that silently leaves them out is narrower than the clause that governs it, and the narrowing should be written down rather than assumed.

Comprehensive Cyber Security Audit Policy Guidelines, v1.0, 25 July 2025

The instrument’s own words

Version-specific details of web and mobile applications must be explicitly mentioned in the audit scope and report.

Read this one carefully: the clause names web and mobile applications and does not name APIs. APIs are the most heavily versioned surface most organisations run, so we ask for the same discipline by contract rather than by clause — and we label that as our reading, not as CERT-In’s requirement.

CERT-In Directions of 28 April 2022, Annexure I

The instrument’s own words

Attacks or malicious/ suspicious activities affecting Cloud computing systems/servers/software/applications

That is the whole item. It names a class of incident and stops: no addressee, no timeframe, no duty. The duty is a different limb of the same instrument — Direction (ii), which requires the entities it binds to “mandatorily report cyber incidents as mentioned in Annexure I to CERT-In within 6 hours of noticing such incidents or being brought to notice about such incidents.” Annexure I supplies the classes, and Direction (ii) supplies the clock. Why it matters here: CERT-In’s own explanation of item (xviii), in the May 2022 FAQ, opens by naming “Cloud API vulnerabilities” before anything else — ahead of weak cryptography, exposed data repositories and unauthorised access to cloud credentials. The API is not a footnote to the cloud incident class. It is the first thing listed in it.

CERT-In SAMVAAD 2026

Our summary of the document — not clause text

Among the topics of the 87-plus presentations selected from more than 200 submissions, the Government of India’s own release names the auditing of cloud systems, APIs and operational technology. The proceedings published on cert-in.org.in list the same among the conference’s discussion topics.

This block is a summary of two documents rather than a clause, because neither document has clauses. What it establishes is precise: API auditing is named as a subject of the national audit ecosystem’s own annual conference. It creates no obligation, sets no methodology and publishes no standard. Reproduce the release’s hedges — “over”, “more than” — and do not convert them into exact counts.

GIGW 3.0, manual — guideline 5.3.1, developer action

Our summary of the document — not clause text

Among the developer actions listed under guideline 5.3.1 for a Government website, web application, portal or mobile app is the use of encrypted channels for third-party APIs.

A summary of one item in a long developer-action list, not a clause quotation — the list is an enumeration rather than a numbered clause. The point it carries is that the Indian Government guideline governing public-sector applications names the third-party API channel expressly. Take the clause numbers from the GIGW 3.0 manual: the live attributes page mis-numbers the third cybersecurity statement, so 5.3.2 appears on it twice.

What a thin finding looks like

Why it fails. No endpoint, so nobody can find it. No request, so nobody can reproduce it. No CWE, so §16.2(ii) is unmet and the finding cannot be counted alongside anything else. No CVSS vector, so the severity cannot be argued with. No evidence in the document, which is what §18(iii) contemplates. And no state check, so a reader cannot tell whether the tester confirmed the read or inferred it from a status code.

What a complete finding looks like

GET /v3/invoices/INV-1001 HTTP/1.1
Host: api.example.test
Authorization: Bearer <A, tenant 1 — redacted>

HTTP/1.1 200 OK
{"id":"INV-1001","tenant":"t1", ...}

GET /v3/invoices/INV-2044 HTTP/1.1
Host: api.example.test
Authorization: Bearer <A, tenant 1 — redacted>

HTTP/1.1 200 OK
{"id":"INV-2044","tenant":"t2", ...}

Ask for one of these before you sign. A redacted sample finding is the cheapest possible test of whether a firm works this way, and it costs them ten minutes. §18(iii) is the standard and §16.2(ii) is the identifier requirement. The control case beside the failing case is the part nobody can fake after the fact.

Endpoints, from a dated inventory

Not screens, not features, not user stories. The route table, reconciled from the specification, the clients and the gateway, with the date §13.2.3(ii)(b) requires in the report.

Distinct privilege levels

The multiplier most quotes ignore. Authorisation testing is combinatorial: every role pair is a test, and the count of meaningful pairs grows faster than the count of roles.

Manual versus tool-assisted split

Enumeration and injection classes are tool-assisted. Authorisation and business-logic classes are not, and cannot be. §13.2.2(ii) makes the test plan state man-hours alongside calendar time so this split is visible.

Protocol shape

REST with one resource per path is the cheap case. GraphQL prices per resolver rather than per path, and ASVS 5.0.0 gives it its own section at V4.3. gRPC, WebSocket and event-driven surfaces each need their own tooling, and V4.4 covers WebSocket.

Environment fidelity

A staging environment that genuinely replicates production, in the §5(xiv) sense, costs less to test than one where half the integrations are stubbed and the tester spends the window establishing which findings are artefacts.

Whether the re-test is inside the price

§13.1.1(g) says the scope of work should clearly specify the requirement to conduct follow-up audits, and §9.3(iv) says they should be included within the scope or RFP — and, where they are, must be conducted by the auditing organisation after closure. §16.3(iv) says follow-up audits should be performed by auditing organisations to verify closure. A proposal without one is priced for half the job, and the half it omits is the half that reduces risk.

A reconciled route inventory, dated

Every route, across every host, from the specification, the clients and the gateway, with the date the inventory was current and the differences resolved to an owner. §16.1(iii) requires all assets provided in scope to be mentioned in the report, so this document and the report’s asset list should be the same list.

The role and account matrix

Which roles exist, how many accounts were issued at each, in how many tenants, when they were issued and when they were revoked. This is the document that tells a later reader which authorisation tests were possible.

A coverage matrix, not a coverage adjective

Routes down one axis, test classes across the other, with what was run and what was not. §16.1(ii) requires the report to carry the detailed scope, the sampling decisions and the “exemptions, limitations and other constraints”. A matrix satisfies that honestly, but “comprehensive testing was performed” does not.

Per-finding request and response pairs

Method, path, headers, body, response status and response body, for both the control case and the failing case, redacted where the data is real. §18(iii) expects observations to be “well supported with objective evidences” compiled with the report, presented so decision makers can use them.

The tool list, with approvals

Tools named, licensing and intellectual-property status confirmed in writing, results of the controlled pre-deployment test formally reviewed and approved by an authorised representative on your side, and written approval before penetration testing and tool installation.

Severity, CWE and, where it exists, CVE

CVSS with the version readable from the vector, EPSS where a CVE exists and an explicit “not applicable” where it does not, and a CWE on every finding. The CVSS bands are FIRST’s scale, so say so rather than presenting them as a CERT-In classification.

Closure timelines by severity

The report “should mention appropriate timelines for closure of vulnerabilities according to severity”. That is the whole clause — it fixes no number of days, so the days come from your own policy and should be stated as yours.

An executive summary that translates

A concise overview for the board and top management that turns the technical findings into business risks. On an API engagement the translation usually reduces to one sentence about data exposure between accounts, and it should be written in those terms rather than in CWE numbers.

The follow-up audit result

Verification of closure by the auditing organisation after remediation, against the previous cycle’s observations. For authorisation findings, ask for the re-test to run at every role pair rather than at the pair that produced the original finding.

The API is somebody else’s and you only consume it

OWASP added API10:2023 Unsafe Consumption of APIs in the 2023 edition for a stated reason: attackers “have started looking for a target’s integrated services to compromise those, instead of hitting the APIs of their target directly”. Data arriving from a third party is input, and it usually crosses your trust boundary with less validation than a user’s form. §13.1.1(f) puts third-party, vendor and supply-chain risk assessment inside the audit scope. Test what your code does with a hostile response from an integration you trust, and treat a redirect returned by a partner as user input rather than as routing.

You publish the API to partners

A partner-facing API has consumers you do not control and cannot notify. Two consequences. Availability-affecting tests need more care, because the blast radius includes somebody else’s production. And §15.2.2(iii) is explicit that testing “must not involve external entities such as customers, business partners, vendors, or other third parties, unless specific written consent is obtained” — so a test that involves a partner’s credentials or a partner’s traffic needs that partner’s written consent, not just yours.

The gateway is run by a cloud provider

§13.1.5(i) draws the split for one named case: a service or website hosted on a web server owned by another organisation. There, responsibility for auditing “the web server, its operating system, the web hosting application software, and any backend database application software lies with the organization that owns and operates the server”, while the data and software related to the website remain the content owner’s to have audited by a CERT-In empanelled organisation. Reading a managed API gateway the same way is our analogy, not the clause’s own example — the clause enumerates a web server, an operating system, hosting software and a backend database, and a managed gateway is none of those. On that reading the configuration is yours and the platform is theirs. Get the line drawn in the scope either way, because the space between “their platform” and “your configuration” is where a permissive policy survives two audits. The same split is the subject of a cloud security audit — see the cloud pages in this cluster.

Serverless functions with their own URLs

A function exposed directly, outside the gateway, with its own hostname and its own authentication decision, deployed by a team that considered it internal. It does not appear in the API specification, no client calls it, and it is absent from the asset inventory the scope must be derived from. This is the discovery problem in its purest form: the control failure is not in the function, it is in the inventory.

The API requires mutual TLS or a client certificate

The tester needs a certificate, and issuing one is a scoping decision with a lead time. §15.1.2 covers it in terms — temporary access “such as login credentials, access tokens, certificates, or secure ID numbers”, revoked on completion. Arrange it before the window, and arrange one per role rather than one shared certificate, or the authorisation matrix collapses back to a single identity.

The mobile client pins its certificate

Pinning stops a tester proxying the app, which is often how the route list is derived. The answers are a debug build without pinning, a documented bypass, or the specification plus the gateway route table in place of client-derived discovery. Whichever is chosen, §13.2.4(ii) asks the auditing organisation to communicate the resulting limitations clearly — so if pinning was not bypassed, the report should say which routes were therefore never observed.

The endpoint in front of you is a model

An inference endpoint is still an API: it has authentication, authorisation, rate limits, input validation and error handling, and every test in the matrix above is worth running against it. What changes is not the test but the evidence. This page’s standard is that an API finding is reproducible with a single request, but where any part of the response is model-generated, a single 200 is an anecdote. Report the finding as successes over attempts at a stated N in fresh sessions, with the five fields set out under the authorisation matrix pinned, or the reproduction means nothing. The consequence at the API layer is the one most easily missed: a retest that fails to reproduce is not closure under §16.3(iv) unless the model version, the system prompt, the sampling parameters and the corpus are all unchanged, because the corpus and the model move underneath both runs — which is why an authorisation defect behind a model endpoint has to be confirmed by reading the state afterwards rather than by reading the response body. CERT-In treats the model’s own behaviour as its own class at §6(xxiii), AI System Audits — “evaluation of AI systems for security, ethical alignment, transparency, data integrity, and resilience to adversarial manipulation”. Do the API layer first, because a model with a broken tenancy boundary in front of it does not need a clever prompt to leak another customer’s data.

The discipline for the model layer itself, including how a reproduction rate is measured and reported, is set out in red teaming an LLM application.

The scope counted screens, not endpoints

A proposal priced against “12 screens” for an application whose frontend calls sixty endpoints. Screens are a client-side unit. The estimate, the coverage and the report all inherit the wrong denominator. Price against the endpoint and role matrix that §13.1.1(c) requires the scope to be derived from.

How you spot it

The scope section counts screens, modules, features or user stories, and no number anywhere in the document is a count of routes.

One account, one role

The most consequential scoping failure, because it removes a whole class rather than reducing coverage within one. Object level authorisation is untestable with one account: the test needs account A, account B and an identifier belonging to B. If the engagement issued one login, the report’s silence on BOLA is a silence about what was not attempted.

How you spot it

The methodology says “an authenticated user account”, singular, and no account matrix appears anywhere. Ask how many were issued, at which roles, in how many tenants.

The specification was taken as the estate

Testing what the OpenAPI file declares and nothing else. Every endpoint added since the file was last regenerated, and every parameter the handler tolerates that the schema does not declare, is out of scope by accident.

How you spot it

The report’s endpoint count equals the specification’s endpoint count exactly. An equal count means no reconciliation ran, because reconciliation almost always moves the number in both directions.

Discovery was not priced, so it was not done

Enumeration is real work and it is the work that determines whether any coverage statement is meaningful. When it is unpriced, it is compressed into the first morning and the estate the test covers is whatever was easy to find.

How you spot it

The man-hours table has no enumeration or discovery line item. Or the endpoint count in the report matches the specification exactly, which means the reconciliation never ran.

Testing went through the edge and the report did not say so

The tester was rate-limited and WAF-filtered like any other client. The result documents the edge’s behaviour. Without an allow-list or a stated limitation, a reader cannot tell which findings were absent and which were merely unreachable that week.

How you spot it

The evidence contains 429 responses. Or no request reproduced in the report ever exceeded a limit. Or the methodology section names a WAF or gateway and the limitations paragraph does not mention it.

Only 200s were checked

An authorisation bypass that returns 403 after performing the side effect reads as a pass in a status-code-driven test. The check is the state afterwards, which means database or log access, which means it has to be arranged before the window.

How you spot it

Every authorisation finding’s evidence is a status code and a response body, and none of them reads the object back afterwards as a privileged account.

GraphQL was treated as one endpoint

A single POST path, hundreds of resolvers, and per-resolver authorisation. Scoping it as one endpoint under-prices it by an order of magnitude. ASVS 5.0.0 gives GraphQL its own section at V4.3 for precisely this reason.

How you spot it

The asset list says “1 endpoint” or names a single /graphql path, and no count of resolvers, queries, mutations or fields appears anywhere in the document.

Webhooks and callbacks were nobody’s

The inbound endpoint that receives a third party’s callback is an unauthenticated write path with a signature check, and it is routinely omitted from both the web scope and the API scope because nobody thinks of it as part of the application.

How you spot it

The asset list contains no inbound callback path, and the report never names a signature scheme — no mention of HMAC, a signing secret, a timestamp window or replay.

Internal and service-to-service APIs were assumed trusted

Reachable from any workload in the cluster, authenticated with a long-lived shared secret, and out of scope because they are “internal”. ASVS 8.3.3 is the relevant requirement: access decisions should follow the originating consumer’s permissions rather than an intermediary service’s.

How you spot it

The scope names only internet-facing hostnames, and the exclusions paragraph is silent — an exclusion that was decided should be written down as one.

The old version was never in the inventory

v1 still routes, shares the production database and predates the authorisation fix. It is not in the specification, no client calls it, and it appears in no asset list. This is the finding that turns a routine engagement into an incident, and the only thing that surfaces it is enumeration.

How you spot it

Every path in the asset list carries the same version prefix. One version present means one version looked for, while two or more means somebody went looking.

Findings were reported without a reproduction

An API finding is a request. A report that describes one without the method, path, headers, body and response has not given the engineering team enough to reproduce, and §18(iii) states that observations are well supported with objective evidences, compiled carefully and correctly with the report.

How you spot it

The evidence is screenshots of a browser or of a tool panel, or the phrase “available on request”, rather than the raw request and response pair.

The re-test was a separate purchase order

Six weeks later, at a new price, after the window in which anyone remembered the context. §13.1.1(g) says the scope of work should clearly specify the requirement to conduct follow-up audits, and §9.3(iv) says they should be included within the scope or RFP. A proposal without one is priced for half the job.

How you spot it

Search the proposal for “re-test”, “retest”, “revalidation” and “follow-up”. If the only hits are in a separate commercial section, the re-test is outside the price.