API penetration test methodology

Volkis will perform penetration testing on the target API. This will include the identification and enumeration of exposed endpoints, authentication and authorisation flows, identification of vulnerabilities, exploitation of identified vulnerabilities, and analysis and reporting of the results.

Our methodology is based on multiple industry recognised methodologies including the OWASP API Security Top 10.

Identification and enumeration

Volkis will investigate the API using a combination of documentation review, traffic analysis, active enumeration, and Open Source Intelligence (OSINT). Where provided, specifications such as OpenAPI/Swagger, Postman collections, GraphQL introspection schemas, WSDL/WADL definitions, and AsyncAPI documents will be ingested to build a complete view of the attack surface. Where documentation is incomplete or absent, endpoints will be discovered by proxying client traffic, brute forcing routes, and examining client-side code including mobile applications and single-page application bundles.

The underlying infrastructure hosting the API will be scanned to identify supporting services, gateways, load balancers, and any adjacent services that could be leveraged to compromise the API or its data. This will include identifying the API gateway or reverse proxy in use (such as Kong, APIM, AWS API Gateway, or NGINX), the application framework (such as Spring, Express, FastAPI, or ASP.NET Core), and any middleware, authentication providers, and identity brokers in the request path.

Endpoint discovery and enumeration will focus on expanding the known surface area. This will include searching for:

• Undocumented or hidden endpoints not listed in the supplied specification;
• Deprecated or legacy API versions still reachable (for example /v1/ alongside /v3/);
• Administrative, internal, or debug endpoints exposed unintentionally;
• UAT, staging, or development instances sharing production data or credentials;
• Shadow endpoints reachable via virtual hosts, path rewrites, or gateway misrouting.

The tester will profile the API to identify the transport and serialisation formats in use (REST/JSON, GraphQL, gRPC, SOAP/XML, WebSocket, Server-Sent Events), the authentication mechanisms presented (OAuth2 and OIDC flows, JWT, API keys, mTLS, HMAC request signing, session cookies), and any rate limiting, WAF, or bot protection in the request path. OSINT sources will be reviewed for leaked credentials, exposed API keys in public code repositories, historical documentation, and references to the API on third party platforms.

Vulnerability identification

Each endpoint, parameter, header, authentication flow, and data object exposed by the API will be investigated for potential vulnerabilities including, but not limited to, the OWASP API Security Top 10. The tester will assess the following areas:

• Authentication flows: OAuth2 grant types and redirect URI handling, OIDC configuration, JWT signing and validation, API key issuance and scoping, mTLS certificate validation, HMAC signature schemes, and any custom authentication logic.
• Session and token handling: token creation entropy, signing algorithm enforcement (including alg:none and algorithm confusion), claim validation (iss, aud, exp, nbf, kid), expiry and refresh behaviour, server-side revocation, replay protection, fixation, and binding of tokens to clients or devices.
• Broken object level authorisation (BOLA/IDOR): direct and indirect object references across tenants, users, and roles, including sequential, UUID, and hashed identifiers.
• Broken function level authorisation: vertical privilege escalation between roles, access to administrative functions from lower-privileged tokens, and HTTP verb tampering.
• Business logic flaws: abuse of intended functionality such as race conditions, workflow bypass, state manipulation, coupon or pricing abuse, and mass assignment of protected fields.
• Input validation and injection: SQL, NoSQL, LDAP, command, SSTI, XXE, SSRF, and deserialisation vulnerabilities across JSON, XML, and binary payloads.
• Header validation: handling of Host, Origin, Referer, X-Forwarded-For, Content-Type, and custom headers used for routing, authorisation, or trust decisions.
• Encryption and signature verification: correct enforcement of TLS, certificate pinning where applicable, verification of request and response signatures, and rejection of tampered payloads.
• IP whitelisting and network trust boundaries: bypass via spoofed forwarding headers, gateway misconfiguration, or access from adjacent networks.
• mTLS and certificate-based trust: validation of client certificates, revocation checking, trust chain enforcement, and behaviour when certificates are missing, expired, or issued by an untrusted CA.
• Rate limiting and resource consumption: unauthenticated and authenticated rate limits, pagination abuse, expensive query construction (particularly in GraphQL), and lack of quotas leading to denial of wallet in cloud-hosted APIs.
• Audit log completeness and integrity: coverage of authentication events, authorisation decisions, data access, and administrative actions; tamper resistance; and inclusion of sufficient context to support investigation.
• Information disclosure: verbose error messages, stack traces, debug endpoints, and leakage of internal identifiers, hostnames, or cloud metadata.

Automated scanning will be used where appropriate, including tools suited to the API style in use. This will be complemented by manual testing, which is essential for API assessments as authorisation logic, business rules, and multi-step workflows are rarely identified by automated tooling alone. The tester will construct test cases that exercise positive and negative authentication states, cross-tenant access, and unexpected input types and sequences to uncover logic flaws that would not surface under normal client behaviour.

Exploitation

The tester will exploit identified vulnerabilities to better understand their impact and to eliminate the possibility of a false-positive.

Exploitation will occur alongside the vulnerability identification phase and will incorporate prioritisation, with vulnerabilities presenting higher risk to the organisation addressed before lower risk issues. Where exploitation carries a meaningful risk of service disruption, data corruption, or impact to other tenants, the tester will organise a window with the client or elect not to exploit the vulnerability at all.

For authentication and authorisation issues, exploitation will typically involve crafting tokens, replaying or tampering with signed requests, forging claims, or accessing objects belonging to other users or tenants using a lower-privileged identity. For injection and deserialisation flaws, tailored payloads will be used to demonstrate data retrieval, code execution, or onward access to supporting infrastructure. For business logic flaws, exploitation will be demonstrated through the smallest number of requests needed to prove the flaw, avoiding broad or destructive actions against production data.

Due to the nature of certain vulnerabilities, not every vulnerability can be exploited by the tester. This could be due to the level of access required, privilege requirements, or specific environmental conditions that need to be in place. These vulnerabilities will still be reported on even if exploitation is not achieved. The lack of exploitation will be a consideration when assessing the risk rating during the risk assessment.

Due to time limitations and prioritisation, not all vulnerabilities that are identified will be exploited during this phase. Sensible precautions will be used during the exploitation phase to minimise the risks of availability issues. If the risks of exploitation are considered greater than the benefit of exploitation, and those risks are not able to be mitigated or managed, the exploitation of the vulnerability will be skipped.

Exploitation of vulnerabilities that specifically create Denial of Service (DoS) conditions will not be performed, nor will any sort of Distributed Denial of Service (DDoS). Rate limiting and resource exhaustion issues will be validated with the minimum traffic required to demonstrate the absence of controls.

Post-exploitation

Successful exploitation of vulnerabilities will provide the tester with additional access to data, functionality, adjacent systems, and in some cases the underlying infrastructure hosting the API. This additional access will be used by the tester to determine and prove the full scope of compromise, including the true business impact of the vulnerability.

Where access to valid tokens, API keys, or service credentials is obtained, the tester will assess the scope of that access against other endpoints, tenants, and backend services such as databases, message queues, and cloud provider APIs. Where the API fronts a cloud environment, metadata services and assumed IAM roles will be assessed within the agreed scope to determine the blast radius of a compromise.

The additional access will be fed back into the previous stages to determine if additional endpoints can be enumerated and additional vulnerabilities can be found and exploited.