API penetration testing.
Testing access controls, tenant isolation and business workflows in the APIs behind web, mobile and partner applications.
- Scope
- REST, GraphQL, gRPC & integrations
- Evidence
- Evidence and recommended fixes
- For
- Australian organisations and product teams
API testing coverage.
- Authentication & sessionsToken handling, session lifecycle, service identities and identity-provider integration, within the systems you are authorised to test.
- Authorisation & tenancyObject, function and field-level permissions across agreed roles, including separation between customer organisations.
- Business workflowsApproval steps, payments, invitations and other sensitive operations, prioritised with your team.
- Data & integrationsSensitive fields, error responses, file handling, callbacks and third-party trust boundaries. Downstream services are included only where permission and test arrangements are established.
- Abuse controlsLimits on sensitive operations and resource use within agreed safety boundaries. Load testing and deliberate availability disruption are separate activities, not assumed parts of the engagement.
What to prepare.
- API inventoryBase URLs, deployed versions, OpenAPI or other schema documentation, and a list of important business workflows. Include partner, internal and older supported versions if they are in scope.
- Roles & test dataRepresentative accounts for each agreed role and, where relevant, more than one test tenant. Use synthetic or approved test records so access boundaries can be assessed without unnecessary exposure of customer data.
- Environment & accessA stable staging environment where possible, network access arrangements and a named engineering contact. Agree production constraints, logging and stop conditions before testing begins.
- Scope boundariesRecord API families, identity providers, web or mobile clients, third-party services and code review as included or excluded. An API assessment does not automatically cover every connected application.
Preparing a brief? Read how to scope an API penetration test for a practical checklist.
What your team receives.
Findings identify the affected endpoint or workflow, required access, evidence, likely impact and recommended fixes. The report includes a prioritised summary.
- Coverage recordThe roles, environments and workflows tested, with access limitations and any areas left untested.
- Findings walkthroughA working discussion of the findings, recommended changes and dependencies between fixes. Sensitive evidence is handled through the agreed reporting channel.
- RetestingAgree which fixes will be checked, the environment, access and retest window in the statement of work. A substantially changed API or new feature may require additional scope.
API testing questions.
How is this different from web application testing?
An API assessment concentrates on service interfaces and the access and business rules they enforce. Browser behaviour, front-end rendering and the wider web application need their own agreed coverage. Our application testing overview explains the broader service.
Do you need source code?
Not always. Working access, documentation and suitable test accounts support an API assessment. Source access can help explain complex authorisation or workflow behaviour; code review is agreed explicitly rather than assumed.
What determines the cost and duration?
Effort depends on endpoint count, workflow complexity, roles, tenants, protocols and integrations. Documentation, access readiness and source-review depth also affect the estimate. We scope these before quoting.
Can we use production?
Only with agreed authorisation, data-handling rules, test windows and stop conditions. Staging may be preferable when it faithfully represents the production controls. The choice is made with your engineering and operations teams.
Discuss the scope and timing.
Tell us what needs testing and when. Keep credentials, source code and customer data out of the initial enquiry; we will arrange a secure exchange if needed.