API Penetration Testing in Australia: A Buyer’s Guide
An API penetration test is a manual security test of the interfaces your software exposes to other software, rather than the screens a person clicks. A tester works through your endpoints with real credentials and tries to read, change or delete data they should not be able to touch. For most Australian businesses it runs one to two weeks, costs less than a full application test, and finds the authorisation and business logic flaws that automated scanners cannot see.
That last point is the whole reason the service exists. The rest of this guide covers what to scope, what to hand over, and what the report should contain.
What is API penetration testing?
API penetration testing is manual security testing of an application programming interface: the REST, GraphQL or SOAP endpoints your mobile app, your single page front end, your integration partners or your customers call directly. A tester is given documentation and at least two sets of credentials, then attempts to break the rules the API is supposed to enforce.
The distinction that matters is who the interface was built for. A web application test drives a browser. An API test ignores the screen entirely and talks to the endpoints underneath it. Plenty of applications enforce permissions in the front end and assume nobody will call the endpoint directly. That assumption is what an API test is designed to find.
Siege Cyber has written separately on web application penetration testing and mobile app penetration testing for SaaS teams. Most products need more than one, and the API layer is the one most often left out.
How is API security testing different from a vulnerability scan?
A vulnerability scanner checks an API against a library of known issues: outdated components, weak transport security, missing headers and injection patterns it has a signature for. It is fast, it is cheap, and it belongs in your build pipeline.
What a scanner cannot do is know your business rules. It does not know that invoice 4821 belongs to a different customer, or that changing one field in a request should not silently promote an account. Those are authorisation and logic flaws, and they are the most common serious findings in API testing, because no automated tool has the context to recognise them.
Both belong in your programme. Scan continuously, test manually once or twice a year and after significant change. The wider comparison is covered in penetration testing versus vulnerability scanning.
What does an API penetration test actually look for?
A credible API penetration test is structured against the OWASP API Security Top 10, the reference list of API specific risks, most recently revised in 2023. You should be able to see every category addressed somewhere in the report.
| Risk category | What the tester tries | Why a scanner misses it |
|---|---|---|
| Broken object level authorisation | Changing an ID in a request to read another customer’s record | It cannot know which records belong to which tenant |
| Broken function level authorisation | Calling an admin endpoint with a standard user token | It does not know which roles are meant to exist |
| Broken object property level authorisation | Adding a field such as a role or a price to a request body | It has no model of which fields a user may set |
| Unrestricted resource consumption | Hammering an expensive endpoint or a password reset | Rate limits often look fine until someone tries |
| Unrestricted access to sensitive business flows | Automating a flow that was designed for one human at a time | The flow is legitimate, only the volume is not |
| Improper inventory management | Finding old versions, staging hosts and forgotten endpoints | It only tests the endpoints you pointed it at |
Improper inventory management deserves a note of its own. In most engagements the tester finds an endpoint the business did not know was reachable: a deprecated version that was never switched off, or a staging host exposed by a firewall change nobody revisited. Those endpoints are rarely patched to the standard of the current release.
What do you need to give a tester before an API penetration test?
The quality of an API penetration test depends almost entirely on what the tester is given at the start. An API gives up very little on inspection, so withholding documentation does not simulate a real attacker so much as waste paid testing time.
- An endpoint inventory. A Swagger or OpenAPI specification, a Postman collection, or at minimum a written list. Include deprecated versions you have not retired.
- At least two accounts per role. Two standard users let the tester attempt to read one user’s data with the other’s token, which is the single most valuable test there is. One account of each role makes that impossible.
- A working authentication flow. How tokens are issued, how long they live, how refresh works. If there is an onboarding step the tester cannot complete alone, say so.
- A test environment that mirrors production. If the test environment has authorisation disabled for convenience, the results will not transfer.
- Known limits. Rate limiting, IP allow lists and firewall rules. Testers can work around them, but they need to know they exist.
- A named technical contact. Someone who can unblock an account lockout the same day rather than the following week.
Siege Cyber’s guide to how to scope a penetration test covers deciding what is in and out of the engagement.
How long does an API penetration test take?
For a typical Australian SMB or SaaS product with a few dozen endpoints, an API penetration test runs one to two weeks of testing, with a report a week after that. The elapsed time from signing to a verified fix is longer, because remediation and retesting sit on your development team’s schedule rather than the tester’s.
Scope drives the testing window more than anything else. Thirty endpoints with two roles is a different job to three hundred with a tenant model and partner integrations. Ask for the estimate in days of testing, so you can see what you are buying.
One question worth asking before you sign: is a retest included, and for how long after? A report tells you what was broken. A retest tells you what is fixed, and that is the document a customer or auditor wants. See ten questions to ask a penetration testing provider.
Does SOC 2 or ISO 27001 require an API penetration test?
Neither SOC 2 nor ISO 27001 names APIs specifically, and neither prescribes a test type. Both expect you to identify your technical vulnerabilities and act on them. If an API carries customer data, an assessment that excludes it is an obvious gap, and an auditor who understands your architecture will say so.
| Framework or driver | What it asks for | Where an API test fits |
|---|---|---|
| SOC 2 | Evidence that vulnerabilities are identified and remediated | Supports the relevant common criteria, usually alongside scanning |
| ISO 27001:2022 | Management of technical vulnerabilities and secure development | Evidence for Annex A controls on testing and vulnerability management |
| PCI DSS v4.0.1 | Testing of systems in the cardholder data environment | Required where an API handles or transmits cardholder data |
| Customer security review | A current test report and a remediation note | Often the real driver, and usually the most specific one |
In practice, Australian businesses rarely commission API testing because a standard told them to. They do it because an enterprise customer asked for a current test report before signing. More detail on the compliance side is in whether penetration testing is required for SOC 2.
How do you tell a good API penetration test report from a bad one?
A weak API penetration test report is a reformatted scanner export: a long list of informational findings and no evidence anyone logged in. A strong report is short on volume and long on specifics.
- Each finding has the exact request and response that demonstrated it, so a developer can reproduce it without a meeting.
- Severity reflects your context, not a generic score. Reading another tenant’s data is critical for a multi-tenant product whatever a database says.
- Authorisation findings are present, or the report explains why none were found.
- There is a clear statement of what was tested and what was not.
- Remediation advice names the fix, not the category. ‘Enforce ownership checks server side on this endpoint’ beats ‘implement access control’.
Reading and acting on the output is a skill of its own, and how to read a penetration testing report covers it properly.
Common questions about API penetration testing
What is the difference between API penetration testing and API security testing?
API security testing is the broad term for any security assessment of an API, including automated scanning, fuzzing and code review. API penetration testing is the manual subset where a tester actively exploits what they find and chains issues together. Buyers use the terms interchangeably, so confirm with any provider whether manual testing is included and how many days of it you are paying for.
Can API penetration testing be automated?
Parts of it can. Discovery, fuzzing and checking for known vulnerable components are all automated in a good engagement, and continuous scanning between tests is worth doing. What cannot be automated is authorisation and business logic testing, because a tool has no way to know which records belong to which customer or which actions a role should be able to take. Those findings require a human who has been told how your product is meant to work.
How often should we test our API?
At least annually, and after any change affecting authentication, the authorisation model or the tenant boundary. A test is a snapshot of one version of your code, so if you ship weekly, pair the annual test with continuous scanning and a rule that significant authorisation changes trigger a review.
How much does API penetration testing cost in Australia?
Cost is driven by the number of endpoints, the number of roles and whether a retest is included, so it is quoted per engagement rather than from a price list. A small single-role API is a fraction of the cost of a multi-tenant platform. Siege Cyber publishes a general guide to penetration testing costs in Australia, and quotes API work on scope.
What methodology should an API penetration test follow?
Ask for testing structured against the OWASP API Security Top 10, with manual authorisation testing called out explicitly in the scope. Also ask who is doing the work and what they hold. CREST accreditation is the clearest signal in the Australian market that a provider’s methodology and reporting have been independently assessed, rather than described well on a website.
Where to start with API penetration testing
Start with an inventory. Before you buy anything, write down every endpoint your business exposes, which are authenticated, and which versions are still reachable. Most teams find something on that list they had forgotten, and that exercise alone improves your position before a tester has touched anything.
Then scope the test around what carries real data and real money, get two accounts per role ready, and insist on a retest. The findings from a good API test are specific, exploitable and fixable, which is more than most security spending delivers.
Siege Cyber is a CREST-accredited Australian penetration testing provider. If you want an API test scoped properly against what your product actually exposes, see our penetration testing services or get in touch for a scoped quote.