What is API penetration testing?
API penetration testing is the assessment of an application programming interface for security weaknesses by calling its endpoints the way an attacker would: enumerating the surface, then testing authentication, object and function level authorisation, input handling and rate controls, and confirming which weaknesses are genuinely exploitable rather than theoretical.
It matters most to the teams who own the endpoints behind a product rather than the screens in front of it.
- Backend and platform engineers shipping REST or GraphQL services where one missing authorisation check can expose an entire dataset.
- Security teams who need proof that an authorisation flaw is reachable before escalating it to the team that owns the service.
- Product teams with partner or public APIs, where the consumer is another system and broken behaviour never shows up in a browser.
- Risk and compliance owners who need API findings mapped to recognised reporting frameworks for an audit or a customer questionnaire.
Why APIs deserve their own penetration test
APIs expose your business logic and data directly, without the browser-side protections that shield traditional web front ends. A single missing authorisation check on one endpoint can expose an entire dataset. And because APIs are built for machines, broken behaviour rarely looks broken to a human clicking through the app.
PentestOps treats APIs as first-class targets alongside web application penetration testing: OWASP API Top 10 coverage for REST and GraphQL services, findings streamed live over WebSocket, and safe, RoE-gated exploitation to prove what is real.
Coverage anchored to the OWASP API Top 10
API risk is dominated by authorisation and authentication failures rather than classic injection alone. PentestOps tests against the OWASP API Top 10 alongside the OWASP Top 10, so API-specific flaws and classic web risks are covered together.
Half of the API Top 10 is some form of access control failure, which is why authorisation testing carries most of the weight in an API assessment. The next section takes all ten categories in turn and says what the platform does for each.
The OWASP API Top 10 2023, category by category
The list below is the 2023 edition in full, with what PentestOps does for each category and where automation stops short. Testing runs from the outside with no credentials supplied, which is exactly what makes an unauthenticated success meaningful evidence rather than a warning.
Where a category depends on knowing your business rules or reading your source code, that is stated rather than counted as covered.
| Category | How PentestOps approaches it | Automated coverage |
|---|---|---|
| API1:2023 Broken Object Level Authorization | Probes object references (IDOR) to confirm whether records belonging to other users can be read or modified. Where a published specification declares an operation as secured, a response carrying valid data with no credentials is reported with the request and response attached. | Strong |
| API2:2023 Broken Authentication | Tests login, token and session handling for bypass paths into protected endpoints, including default and weak credentials on exposed services. | Strong |
| API3:2023 Broken Object Property Level Authorization | Responses are inspected for properties that should never reach the caller, such as credentials, tokens or personal identifiers returned alongside legitimate data by an over-permissive serialiser. Mass assignment on write operations is only tested when write methods are explicitly authorised for the engagement. | Partial |
| API4:2023 Unrestricted Resource Consumption | Sends a small, bounded burst and looks for any rate-limiting signal at all: an HTTP 429, a Retry-After, or rate-limit response headers. Testing stays deliberately conservative, so a missing control is reported as a gap rather than proven by exhausting your API. | Partial |
| API5:2023 Broken Function Level Authorization | Checks whether administrative or privileged operations respond to unprivileged or unauthenticated callers, including operations a published specification marks as requiring authentication. | Strong |
| API6:2023 Unrestricted Access to Sensitive Business Flows | Automation can show that a flow is reachable and unthrottled, but deciding which flows are business-sensitive is a judgement about your business. Flag those flows during scoping; designing the abuse cases around them remains human work. | Limited |
| API7:2023 Server Side Request Forgery | Targets endpoints that fetch remote resources to confirm whether internal services are reachable from the API. | Strong |
| API8:2023 Security Misconfiguration | Audits exposed services, transport security, cross-origin policy and error handling, correlated against CVEs with CISA KEV prioritisation. | Strong |
| API9:2023 Improper Inventory Management | Discovery surfaces hosts, subdomains and endpoints outside your documented inventory, and operations a specification marks as deprecated that still respond are reported. Old versions left running are a routine finding. | Strong |
| API10:2023 Unsafe Consumption of APIs | Third-party services your API consumes sit outside the tested scope and outside your Rules of Engagement. Outbound integrations that are observable from the outside are reported, but the trust your code places in a partner response is reviewed in code, not from the outside. | Limited |
What the coverage ratings mean
The third column is deliberately not a row of ticks. It describes how much of each category automated testing can settle on its own.
- Strong. Directly testable from outside the API, and confirmed findings arrive with evidence and safe exploitation behind them.
- Partial. Real issues in the category are found, but part of it depends on write access, source code or business context that a conservative external test does not have.
- Limited. Automation contributes evidence rather than a verdict. The category needs a person to interpret it, and padding a coverage claim would not change that.
Using your OpenAPI specification to define the tested surface
An API is only as testable as its surface is known. Where your service publishes an OpenAPI 3 or Swagger 2 document, PentestOps reads it and uses the operations it declares to define what gets tested, instead of guessing endpoints from the outside.
The specification is discovered rather than uploaded: the scan looks for a document at the locations services conventionally publish one. Every path and method it declares, whether an operation is marked as requiring authentication, and whether it is marked deprecated all feed the test plan.
- Declared intent becomes a test. An operation the specification says is secured, which returns valid data with no credentials supplied, is reported as broken object level or function level authorisation with the request and response as evidence.
- Deprecated but live is a finding. Operations marked deprecated that still respond are reported as improper inventory management, which is how old versions quietly stay reachable long after the docs say otherwise.
- Safe methods by default. Only GET, HEAD and OPTIONS are sent unless write methods are explicitly authorised for the engagement, so a specification-driven scan does not mutate your data by accident.
- Volume is capped. The number of documented operations exercised in a run is capped, so a large specification cannot turn a scan into a flood against your API.
- Publishing the document is itself reported. Readable production API documentation is a finding in its own right: it improves our coverage and it improves an attacker's just as much.
If your specification is not published
Keeping the document off the public internet is the right call, and it does not leave testing blind. Discovery still drives scope: subdomain enumeration, exposed-service detection and attack-surface mapping routinely surface endpoints that never made it into the documented inventory.
Coverage is then bounded by what is reachable from outside, so the stronger move is to define scope yourself. Bring the endpoints you already know about into the asset inventory, including by bulk CSV or XLSX import, and testing works from your list rather than from whatever a crawler happens to find. Assets are re-verified every 7 days with drift detection, so the list stays honest as the API changes. See platform features.
REST and GraphQL, one workflow
REST and GraphQL services are both supported. The same authorisation, authentication and injection testing applies whether the surface is a versioned REST resource or a GraphQL query, and results land in the same live finding stream with the same evidence standards.
Scan profiles (Stealth, Balanced and Aggressive) let you match testing intensity to the target, from a careful, rate-conscious pass over a production API to a thorough pre-release assessment of a staging environment.
How an API pentest runs
API testing follows the same 7-phase methodology as every PentestOps engagement, built on PTES, the OWASP Web Security Testing Guide v4.2 and NIST SP 800-115, aligned to CREST guidance.
- Scope and authorise. Add each API host as an asset and sign the Rules of Engagement that gate all testing.
- Pick a profile. Stealth, Balanced or Aggressive to suit the environment.
- Discover. Subdomain enumeration, exposed-service detection and attack-surface mapping surface endpoints you may have forgotten.
- Test. OWASP API Top 10 and OWASP Top 10 testing across REST and GraphQL, including auth bypass, IDOR and SSRF.
- Validate. Safe exploitation proves which findings are exploitable; a strategy engine auto-picks the best technique per finding.
- Stream. Findings arrive live over WebSocket, prioritised by CVSS v3.1, exploit availability and CISA KEV.
- Report. Compliance-mapped reports in multiple formats including PDF, CSV and JSON/API, plus AI-guided remediation steps.
Authorisation testing: where APIs actually break
The most damaging API flaws are rarely exotic. They are object-level authorisation failures: an endpoint accepts an ID, and nothing checks whose ID it is. PentestOps probes object references and privileged functions to confirm whether other users' data, or admin-only functionality, is reachable without proper authorisation.
Confirmed authorisation flaws ship with evidence showing exactly what was reached and how, so developers can reproduce and fix the issue quickly. For the engineering side of the problem, see our guide to API security best practices.
Internal and partner-facing APIs
APIs that serve internal systems or trusted partners often skip the scrutiny public endpoints get, while carrying more privilege. The PentestOps on-prem agent reaches them without network re-engineering: it deploys in about 5 minutes as a Docker container, RPM or DEB package, connects outbound-only over TLS 443 and requires 0 inbound firewall rules. Internal APIs get the same OWASP API Top 10 coverage as your public surface.
Why PentestOps for API security
API testing is not an add-on module bolted to a network scanner. It is part of the same platform, methodology and evidence pipeline as every other PentestOps assessment.
- Included from Starter. API scanning is in every plan, with scheduled scans and scan comparison from Professional. See pricing.
- Asset-wise pricing. One API host is one asset, with unlimited scans within fair use.
- Evidence over noise. Safe exploitation and false-positive reduction keep the queue focused on provable risk.
- Self-hosted AI by default. Risk scoring, attack chain prediction and reporting without sending scan data to third-party model providers.
- Compliance-ready output. Findings map to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes.
- Australian-built and hosted. The platform is hosted in Australia, and customer data is stored in Australia. Extranet Systems Pty Ltd is ISO/IEC 27001:2022 certified.