Advisory

API Penetration Testing in Australia

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 in Australia for REST, GraphQL and gRPC.

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.

API Penetration Testing

What an API penetration test involves.

Every API is different, so every engagement is scoped to its endpoints, roles and environment. This is the common ground.

  • API styles

    REST, GraphQL and gRPC, including public, partner, internal and machine-to-machine APIs.

  • What we need

    An OpenAPI or Swagger file, Postman collection or GraphQL schema, with test accounts for each role.

  • Standards

    OWASP Top 10 and OWASP ASVS Level 2, inside our six-step CREST-aligned method.

  • Led by

    A CREST-registered Practitioner or Senior Consultant, with testers based in Australia.

  • After the test

    Debrief, developer walkthrough, retest of High-and-above findings and 90 days of portal access.

What we test in an API penetration test.

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.

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.

Authentication and token handling

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.

Function-level authorisation

Ordinary users should not reach administrative operations. We call privileged methods with low-privilege tokens to find missing checks.

Excessive data exposure

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.

Rate limiting and resource abuse

We check whether attackers could guess credentials, scrape data or exhaust resources because limits are missing, weak or easily bypassed.

GraphQL introspection and query depth

We probe introspection, nested and batched queries, aliases and field-level authorisation, which standard REST tooling tends to miss.

gRPC services

We test Protocol Buffer services for weak authentication, unvalidated messages and trust assumptions between internal microservices.

Back-end APIs for web and mobile

The APIs behind your website and mobile apps are tested directly, without the client's restrictions, because that is how an attacker approaches them.

When you need an API penetration test.

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.

What makes an API pen test worth the effort.

An API test that only replays a scanner's requests will miss most of the real risk. Ours is built around four habits.

A token for every role

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.

Manual work on every endpoint

Burp Suite helps us capture and replay traffic, but testers write and adjust each request themselves. Every High-and-above finding is confirmed manually.

CREST-accredited delivery

Vectra's six CREST accreditations include App Security Testing. A CREST-registered Practitioner or Senior Consultant leads each engagement.

Front end and back end together

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.

Our API penetration testing method.

The six CREST-aligned steps we use on every engagement, applied to an API.

  1. Step 1: Scope & kick-off

    We collect your OpenAPI or Swagger file, Postman collection or GraphQL schema, plus test accounts and tokens for each role and tenant.

  2. Step 2: Threat modelling

    We identify the sensitive objects your API exposes, which identities may touch them, and where your services trust each other.

  3. Step 3: Reconnaissance

    Beyond the documented endpoints, we hunt for older API versions, debug routes, hidden parameters and anything left out of your inventory.

  4. Step 4: Exploitation

    Testers tamper with object identifiers, tokens, request bodies and request rates, producing a proof of exploit for each High-and-above issue.

  5. Step 5: Post-exploitation

    We follow each foothold further: into internal services, cloud metadata, connected partners or bulk extraction of customer data.

  6. Step 6: Reporting & retest

    Every finding names the endpoint and method, with the request and response that prove it. Fixed issues are then retested.

API pen test deliverables.

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.

  • Endpoint-level findings

    The endpoint, method, parameters and role involved, with reproduction steps your developers can follow.

  • Ranked remediation roadmap

    Issues ranked by business impact, with developer-ready fixes and suggested code changes where they apply.

  • Narrative summary for leaders

    A separate executive report that explains exposure in business, legal and reputational terms.

  • Developer walkthrough and retest

    A session with your engineers, then a retest window for every High-severity finding and above.

Compliance an API penetration test supports.

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.

  • PCI DSS

    Payment and card-data APIs inside your cardholder data environment fall under the requirement 11.4 penetration testing obligations.

  • APRA CPS 234

    Banks, insurers and superannuation funds must test information security controls, including those guarding customer data APIs.

  • ISO 27001

    Security testing of new and changed APIs supports Annex A control 8.29 on testing in development and acceptance.

  • Privacy Act (APP 11)

    APIs that return personal information are a common breach path. Testing them is a reasonable step to protect that data.

  • Partner and customer assurance

    Organisations that integrate with your API often ask for a recent independent test before they connect.

Scoped quotes for API testing.

Effort follows the number of endpoints, roles and tenants, so we quote each API against its own scope.

Tests that pair well with an API pen test.

An API is usually one layer of a larger system. These engagements cover the layers around it.

Web application penetration testing

The browser front end on top of your API, including sessions, business logic and client-side code.

Mobile app penetration testing

iOS and Android clients that call your API, including how they store tokens and pin certificates.

Cloud penetration testing

The gateways, functions, identities and storage that host your API in AWS, Azure or Google Cloud.

Penetration testing services

Every test type we deliver, our six CREST accreditations and our offices across Australia.

API penetration testing FAQs.

What do you need from us for an API pentest?

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.

Can you test an API without documentation?

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.

Can you test internal or partner APIs?

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.

Do you test API gateways and WAF rules?

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.

Do you test GraphQL and gRPC as well as REST?

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.

How is an API penetration test scoped?

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.

Start with a conversation.

Speak to us about your cyber governance and compliance requirements.

Send us a message

What can we help with?

A sentence or two is plenty. We'll ask for detail when we reply.