API Penetration Testing in Australia: What to Prepare
An API penetration test is a manual security test in which a tester holds valid credentials and tries to reach data and functions belonging to another account. To run one you need to supply six things: a current OpenAPI or Swagger specification, at least two test accounts per user role, a non-production environment with realistic data, documented authentication tokens, rate limits and WAF rules lifted for the tester, and a named technical contact. Supply those and a single API of 40 to 80 endpoints is usually tested inside two weeks.
The rest of this guide explains what the test looks for, why it finds things a web application test does not, and how Australian teams decide how often to run one.
What is API penetration testing?
API penetration testing is a manual security assessment of an application programming interface, carried out by a tester who has been given legitimate credentials and then tries to exceed them. The tester works through each endpoint asking whether the API checks that the caller is allowed to perform the action on that particular record, rather than only whether the caller is logged in.
The distinction matters because most APIs authenticate well and authorise badly. A user proves who they are, and the API then trusts an identifier in the request to decide which record to return. Changing that identifier to someone else’s is not a clever exploit. It is a single character edit, and it is the most common serious finding in API testing.
The reference framework is the OWASP API Security Top 10, whose 2023 edition puts broken object level authorisation at number one. Australian testers, including CREST accredited ones, map their API methodology to it.
What does an API penetration test actually cover?
An API penetration test covers authorisation, authentication, business logic, data exposure, resource consumption and inventory. A tester works through the API endpoint by endpoint rather than crawling a website, because an API has no navigation to crawl.
- Object level authorisation. Can account A read, edit or delete account B’s records by changing an identifier in the request?
- Function level authorisation. Can a standard user call an endpoint that only an administrator should reach?
- Authentication and token handling. Do tokens expire, can they be replayed, and does logout actually invalidate them?
- Excessive data exposure. Does the response contain fields the interface never displays, such as internal notes, password hashes or another user’s email address?
- Business logic. Can an order be repriced, a trial extended, or an approval step skipped by calling endpoints out of order?
- Resource consumption. Can one caller exhaust the service, run up a cloud bill, or trigger unlimited emails or SMS messages?
- Inventory. Are old versions such as /v1 still live and unpatched alongside /v3, and are staging endpoints reachable from the internet?
Testing these properly requires more than one account. A tester with a single login can confirm an endpoint responds, but cannot prove the API stops one customer reaching another customer’s data.
What do you need to give your tester before day one?
Six items decide whether the first week of an API penetration test is spent testing or waiting. Access problems are the single largest cause of lost days on API engagements, and the days are billed either way.
- A current API specification. An OpenAPI or Swagger file, or an exported Postman collection. Without it the tester spends days discovering endpoints you could have listed in an hour, and coverage is never complete.
- Two accounts per role. Two standard users, two administrators, and two accounts in separate tenants if your product is multi-tenant. Cross-account testing is impossible with one account each.
- A non-production environment. Same authentication flow, same code version, realistic data volumes. A staging environment with three records will not surface pagination or export flaws.
- Documented authentication. How tokens are issued, how long they live, and how they refresh. Tokens that expire in fifteen minutes with no refresh path will stall an engagement.
- Rate limits and WAF rules lifted. Allow-list the tester source addresses. A test that is blocked at the edge tells you your WAF works, not whether your API is safe behind it.
- A named technical contact. One engineer who can unblock access the same day. Not a shared inbox.
Siege Cyber walks through this list on the scoping call, and it also appears in our penetration test preparation checklist.
How is API penetration testing different from web application testing?
A web application penetration test exercises the interface a person clicks through. An API penetration test exercises the endpoints directly, without the interface, which is how an attacker reaches them. The two tests find different classes of problem, and a scope that names only the web application will usually leave most API endpoints untested.
| Question | Web application test | API penetration test |
|---|---|---|
| How targets are found | Crawling links and forms in the browser | Reading an OpenAPI spec or proxying live traffic |
| Typical top finding | Cross-site scripting, injection, session handling | Broken object level authorisation, excessive data exposure |
| Hidden functions | Limited to what the interface renders | Endpoints the interface never calls are still reachable |
| Accounts needed | Often one per role | Two per role, plus two tenants for multi-tenant products |
| What it proves | A user cannot break the application through the browser | A caller cannot exceed their permissions at the endpoint |
If your product is a single page application talking to a JSON backend, the browser is only a client, and scoping the browser alone leaves the backend untested. Our guides to web application penetration testing and mobile application testing cover the client side.
Is an API penetration test the same as a DAST scan?
No. A dynamic application security testing scan is automated and looks for known vulnerability patterns in responses. An API penetration test is manual and looks for logic and authorisation failures that are specific to your data model. A scanner cannot know that invoice 4812 belongs to a different customer, so it cannot tell you that returning it was wrong.
Automated scanning still has a place. Run it continuously in your pipeline to catch regressions and known component vulnerabilities, then use manual testing for the authorisation and business logic questions a scanner cannot frame. The difference is set out in more detail in penetration testing versus vulnerability scanning.
What drives the scope and price of an API penetration test?
Four factors drive the size of an API penetration test: endpoint count, the number of distinct user roles, whether the product is multi-tenant, and whether a retest is included. Roles multiply the work, because every authorisation test is repeated for each pair of roles.
| Scoping factor | Low effort | High effort |
|---|---|---|
| Endpoints | Under 40 | 200 or more, or an undocumented estate |
| User roles | One or two | Five or more, with custom permission sets |
| Tenancy | Single tenant | Multi-tenant with shared infrastructure |
| Documentation | Current OpenAPI spec | No spec, endpoints discovered during the test |
| Retest | Not required | Full retest and an attestation letter for customers |
Siege Cyber quotes API testing on a fixed price basis once scope is agreed, so the number does not move mid-engagement. Indicative market ranges for Australian testing are set out in our penetration testing cost guide, and the mechanics of agreeing a scope are covered in how to scope a penetration test.
How long does an API penetration test take?
For a single API with 40 to 80 endpoints and two or three roles, expect roughly two weeks of elapsed time from the start of testing to the report, plus a scoping call beforehand and a retest a few weeks later once your team has made fixes. Larger estates and undocumented APIs take longer, mostly because discovery eats into testing time.
The retest matters commercially. A report listing open findings is a liability in a procurement review, while a report plus a retest letter is an asset. See reading and acting on a penetration testing report for what each document is for.
How often should API penetration testing be performed?
Most Australian businesses test their APIs annually, and again after any material change to authentication, permissions or tenancy. Annual is also the cadence compliance frameworks and enterprise customers expect.
- Annually. The baseline for any production API that handles customer data.
- After a permissions change. New roles, a new tenancy model or a migration to a new identity provider all reopen the authorisation questions.
- Before a major customer review. An enterprise or government buyer will usually ask for a report dated within the last twelve months.
- After a significant new feature. A new set of endpoints that touches billing, exports or user management deserves its own test rather than waiting for the annual cycle.
Common questions
What is API penetration testing in simple terms?
It is a manual test in which a security tester is given a real account on your system and then tries to use it to reach data or functions that belong to someone else. The tester works directly against your endpoints rather than through the user interface, because that is how an attacker with a stolen token would work.
What is the difference between DAST and penetration testing?
Dynamic application security testing is automated pattern matching against your running application. Penetration testing is a person reasoning about your specific data model and permissions. DAST is good at catching known vulnerability classes quickly and cheaply. It cannot tell you that one customer can read another customer’s invoices, which is the most common serious API finding.
What is the API penetration testing methodology?
Most Australian testers follow a four stage methodology: enumerate every endpoint from the specification and live traffic, map the permission model by role, attempt to cross those boundaries with valid credentials, then verify the business logic by calling endpoints out of the intended order. Findings are then ranked by business impact rather than by raw severity.
How often should API penetration testing be performed?
Annually for any production API that handles customer data, plus an extra test after any change to authentication, roles or tenancy. Enterprise buyers and compliance frameworks generally expect a report dated within the last twelve months, so an annual cycle usually satisfies both the security and the commercial requirement at once.
Do I need an API test if I already have a web application test?
Usually yes. A web application test exercises what the browser renders. If your product is a single page application or a mobile app, most endpoints are never called by the interface the tester clicks through, so they go untested. Ask your provider to state plainly which endpoints were in scope.
Can API penetration testing be automated?
Partly. Automation suits endpoint discovery, known component vulnerabilities and catching regressions between manual tests. It does not suit authorisation testing, because a tool has no way of knowing which records a given account should be able to see. Use both, and do not accept a scan report presented as a penetration test.
Where to start with API penetration testing
If you have an API in production and have never had it tested, start with a scoping conversation about endpoint count, roles and tenancy. That is usually enough to establish whether you need a two week engagement or something larger.
Siege Cyber runs fixed price API penetration testing for Australian businesses, with a retest included so you finish with evidence you can give a customer. Learn more about our penetration testing services or get in touch to talk through scope.