API Penetration Testing
What is an API penetration test?
An API (Application Programming Interface) is the layer that lets different systems talk to each other such as your mobile app talking to your backend, your web application fetching data, your platform connecting to third-party services. Most modern applications rely heavily on APIs, and they are an increasingly common target for attackers because they often expose the same data and functionality as the front end but with fewer of the controls that get applied to user-facing interfaces.
An API penetration test assesses your APIs the way an attacker would, looking for vulnerabilities that could be used to access data you didn't intend to expose, perform actions that should be restricted, or bypass the controls your application depends on.
What we test
Our API penetration tests are structured around the OWASP API Security Top 10, which documents the most common and impactful categories of API vulnerability. In practice that means we look at:
Broken object level authorisation - whether the API properly checks that the requesting user is allowed to access the specific object they are asking for. This is the most common API vulnerability and can allow an attacker to access any user's data simply by changing an ID in the request.
Broken authentication - whether authentication mechanisms can be bypassed, whether tokens are properly validated, whether session handling is implemented correctly, and whether there are endpoints that skip authentication checks entirely.
Broken object property level authorisation - whether the API returns more data than the requesting user should be able to see, or accepts input that modifies fields the user should not be able to change.
Unrestricted resource consumption - whether the API implements rate limiting and whether it is possible to cause denial of service or run up costs by making large numbers of requests or requests that consume significant server resources.
Broken function level authorisation - whether administrative or privileged API endpoints are properly restricted, or whether a standard user can call functions intended only for administrators.
Injection vulnerabilities - whether the API is vulnerable to SQL injection, command injection or other injection flaws through the parameters it accepts.
Security misconfiguration - default settings, unnecessary HTTP methods enabled, overly permissive CORS policies, missing security headers, and verbose error messages that reveal internal system details.
Improper inventory management - whether older API versions are still accessible and whether deprecated endpoints that may have weaker controls remain reachable.
Who needs an API penetration test?
If your product exposes an API to customers, to partners, or to your own front-end applications then that API is part of your attack surface. A vulnerability in your API can be just as damaging as one in your web application, and often more so because APIs tend to have direct access to data with less filtering applied.
APIs connect your systems to payment providers, identity platforms, CRMs, and other services. Understanding whether those integrations are implemented securely is part of understanding your overall exposure.
Where an API is in scope for PCI DSS, such as an API that handles or transmits cardholder data, it needs to be included in penetration testing. ISO 27001 assessments should also cover APIs that handle sensitive data or provide access to critical systems.
Before launching or significantly updating an API. New APIs and major version updates are the right time to test, before customers or partners are relying on the interface and before a vulnerability has had time to be exploited.
What the process looks like
We start with a scoping call to understand what APIs you have, what they do, and what level of documentation is available. API testing works best when we have access to API documentation such as a Swagger or OpenAPI specification, which lets us work through the full set of endpoints systematically. Where documentation does not exist, we can work from traffic captures or explore the API directly, though this takes longer.
Testing is conducted in a grey-box model in most cases, we have credentials representing different user roles and some context about how the API is intended to work, which allows us to test authorisation controls thoroughly and find the logic-level issues that a purely black-box approach would miss.
Testing typically runs over a number of days depending on the number of endpoints and the complexity of the authorisation model. The report covers each finding with a severity rating, a clear explanation of what it means and what an attacker could do with it, and specific remediation guidance for your development team.
Retesting
Once your development team has addressed the findings, we offer a retest to confirm the fixes are effective. This is particularly useful before a product launch, a security audit, or when demonstrating remediation to a customer or compliance assessor.
Based in Auckland, working across New Zealand
API testing is conducted remotely and works equally well for businesses anywhere in New Zealand.