Broken object-level authorisation
The most common serious API flaw. We swap object IDs between accounts and tenants to see whether your API returns records the caller should never see.
Manual testing of REST, GraphQL and gRPC APIs by a CREST-accredited team based in Australia. We look for the authorisation and data exposure flaws that automated scanners miss.
API penetration testing checks whether the interfaces behind your apps, partners and integrations can be abused to reach data or functions they should protect. Vectra is a CREST-accredited penetration testing company, and our testers are based in Australia. We test REST, GraphQL and gRPC APIs, whether they serve a web front end, a mobile app, a business partner or another machine. APIs fail in their own way: a request that looks perfectly valid can still return another customer's records. That is why our testers work through each endpoint by hand, holding real tokens for every role, and prove each High-and-above finding with a working exploit.
Every API is different, so every engagement is scoped to its endpoints, roles and environment. This is the common ground.
REST, GraphQL and gRPC, including public, partner, internal and machine-to-machine APIs.
An OpenAPI or Swagger file, Postman collection or GraphQL schema, with test accounts for each role.
OWASP Top 10 and OWASP ASVS Level 2, inside our six-step CREST-aligned method.
A CREST-registered Practitioner or Senior Consultant, with testers based in Australia.
Debrief, developer walkthrough, retest of High-and-above findings and 90 days of portal access.
The areas below include the main risks named in the OWASP API Security Top 10. From there, our testers follow the logic of your own API wherever it leads.
The most common serious API flaw. We swap object IDs between accounts and tenants to see whether your API returns records the caller should never see.
We examine OAuth 2.0 flows, JSON Web Token signing and expiry, API keys and refresh tokens, looking for tokens that can be forged, replayed or stretched.
Ordinary users should not reach administrative operations. We call privileged methods with low-privilege tokens to find missing checks.
Responses often carry far more fields than the app displays. We look for leaked personal data, internal flags and properties a caller can overwrite through mass assignment.
We check whether attackers could guess credentials, scrape data or exhaust resources because limits are missing, weak or easily bypassed.
We probe introspection, nested and batched queries, aliases and field-level authorisation, which standard REST tooling tends to miss.
We test Protocol Buffer services for weak authentication, unvalidated messages and trust assumptions between internal microservices.
The APIs behind your website and mobile apps are tested directly, without the client's restrictions, because that is how an attacker approaches them.
Most organisations now expose more through APIs than through web pages. These are the moments to test them.
Before a public or partner API is released.
When you open an API to new partners, resellers or integrations.
After moving to a new identity provider, token format or API gateway.
Before a mobile or web release that adds new endpoints.
When APIs handle payments, health records or other regulated data.
After decommissioning old API versions, to confirm they are really gone.
An API test that only replays a scanner's requests will miss most of the real risk. Ours is built around four habits.
We test with separate credentials for each user type and tenant, because most serious API flaws only appear when one identity requests another identity's objects.
Burp Suite helps us capture and replay traffic, but testers write and adjust each request themselves. Every High-and-above finding is confirmed manually.
Vectra's six CREST accreditations include App Security Testing. A CREST-registered Practitioner or Senior Consultant leads each engagement.
When the same API serves your website and mobile app, we can test all three in one scope, so findings are reported once and fixed once.
The six CREST-aligned steps we use on every engagement, applied to an API.
We collect your OpenAPI or Swagger file, Postman collection or GraphQL schema, plus test accounts and tokens for each role and tenant.
We identify the sensitive objects your API exposes, which identities may touch them, and where your services trust each other.
Beyond the documented endpoints, we hunt for older API versions, debug routes, hidden parameters and anything left out of your inventory.
Testers tamper with object identifiers, tokens, request bodies and request rates, producing a proof of exploit for each High-and-above issue.
We follow each foothold further: into internal services, cloud metadata, connected partners or bulk extraction of customer data.
Every finding names the endpoint and method, with the request and response that prove it. Fixed issues are then retested.
API findings are only useful if a developer can reproduce them quickly. Every issue in our report comes with the exact request, the response and the reason it matters.
Each engagement also includes the standard Vectra deliverables described on our penetration testing page.
The endpoint, method, parameters and role involved, with reproduction steps your developers can follow.
Issues ranked by business impact, with developer-ready fixes and suggested code changes where they apply.
A separate executive report that explains exposure in business, legal and reputational terms.
A session with your engineers, then a retest window for every High-severity finding and above.
APIs carry the same regulated data as the applications on top of them, so auditors increasingly want to see them tested. Our reports can be mapped to PCI DSS, ISO 27001, APRA CPS 234, SOCI Act, Essential Eight and IRAP obligations where required.
Payment and card-data APIs inside your cardholder data environment fall under the requirement 11.4 penetration testing obligations.
Banks, insurers and superannuation funds must test information security controls, including those guarding customer data APIs.
Security testing of new and changed APIs supports Annex A control 8.29 on testing in development and acceptance.
APIs that return personal information are a common breach path. Testing them is a reasonable step to protect that data.
Organisations that integrate with your API often ask for a recent independent test before they connect.
Effort follows the number of endpoints, roles and tenants, so we quote each API against its own scope.
An API is usually one layer of a larger system. These engagements cover the layers around it.
The browser front end on top of your API, including sessions, business logic and client-side code.
iOS and Android clients that call your API, including how they store tokens and pin certificates.
The gateways, functions, identities and storage that host your API in AWS, Azure or Google Cloud.
Every test type we deliver, our six CREST accreditations and our offices across Australia.
The most useful inputs are an OpenAPI or Swagger file, a Postman collection or a GraphQL schema, plus working test accounts or tokens for every role and tenant. Tell us which environment to test and any rate limits or fragile endpoints we should respect. The better the documentation, the more of the testing time goes on finding real flaws.
Yes. We can map an undocumented API by capturing the traffic from your web or mobile app and probing for endpoints the client never calls. That discovery work takes extra effort, so it is reflected in the scope. It often uncovers forgotten versions and debug routes, which are findings in their own right.
Yes, provided we can reach them. Internal APIs can be tested through a VPN, an allow-listed address or a test host on your network. Partner APIs need written permission from whoever operates them. Machine-to-machine APIs are tested with the same service credentials your integrations use, so we see exactly what a compromised integration could do.
Yes. We can test both ways: once through the gateway and web application firewall, to see what they block, and once with our addresses allow-listed, to test the API itself. A WAF can hide a flaw from casual probing without fixing it. Testing both ways shows whether your protection depends on that single layer.
Yes. GraphQL brings its own risks, including open introspection, deeply nested queries, batched requests that dodge rate limits and resolvers that skip authorisation. gRPC services need tooling that speaks Protocol Buffers, and they are often assumed to be internal and safe. We test each style with methods suited to it, not REST checks forced to fit.
Scope depends on the number of endpoints or operations, the number of roles and tenants, the API styles involved and whether documentation exists. We scope and quote each API to its environment.
Speak to us about your cyber governance and compliance requirements.
Message sent
A member of our team will be in touch soon at . You can also reach us during business hours on 1800 816 044.
Need us sooner? Call +61 8 8208 0800, or the 24/7 incident line on 1800 816 044 if something is happening now.