API Penetration Testing Checklist: What to Test, Prepare and Expect (2026)

One API, queried without authorization for about six weeks, gave up data from approximately 37 million T-Mobile customer accounts, according to the Form 8-K the company filed on 19 January 2023. The filing describes no malware and no network intrusion. It describes "a single Application Programming Interface" that answered requests from about 25 November 2022 until the company identified the activity on 5 January 2023, and it does not say which control failed. An API penetration test exists to find that kind of failure first, and the OWASP API Security Top 10, unchanged since its stable release on 5 June 2023, shows where to look: four of its first five risks are authentication or authorization failures.

Quick answer. An API penetration testing checklist has three parts. Before the test: an inventory of every API host and version, a specification, two accounts per role, a second tenant, and agreed limits for rate-limit and lockout testing. During the test: each of the ten OWASP API Security Top 10 2023 risks, checked with authenticated requests across roles and tenants, plus token handling, API keys, GraphQL, webhooks and injection. After the test: a report that names the endpoints and identities tested, shows the request and response behind every finding, records what passed, and includes the retest result.

This guide is written for engineering and security leads who are about to buy or run an API test. It lists what to prepare, what a competent tester checks, and what evidence to expect at the end. It describes test activities and results, not attack recipes, so it can be handed to a development team or pasted into a statement of work as it stands.

API security testing vs API penetration testing

"API security testing" is the umbrella term. It covers everything from linting an OpenAPI file in the build to a full penetration test, and the methods answer different questions.

The third row is the one whose coverage is easiest to overestimate. CISA, the NSA and the Australian Cyber Security Centre recommend dynamic testing tools in their joint advisory on access control abuse, then add a warning: "Not all DAST tools can detect IDOR vulnerabilities". The reason is covered in why automated API scanners miss BOLA and IDOR. Scanning and fuzzing still belong in the pipeline. OWASP itself notes that fuzzing "is usually used to identify additional (hidden) properties" in API objects.

Stingrai's own numbers point the same way. In the State of Penetration Testing 2026 dataset, 70% of the 40 web application tests that produced findings surfaced at least one High or Critical authentication or authorization finding. Those are the classes that need a tester, or an agent built for the job, holding several identities at once. The rest of this checklist is about that fourth row.

Before the test: the preparation checklist

Whether an API penetration test finds the serious flaws is decided largely by what the tester receives on day one. A test run with one account against the documented endpoints cannot check most of the OWASP list. Use this table as the kickoff agenda.

Figure 1: What each part of the test needs from the buyer. Mapping by Stingrai against the OWASP API Security Top 10 2023.

In this mapping, five of the ten checks cannot be done without at least two accounts per role, and two more cannot be done without a host and version inventory. Only the server side request forgery check can start from a single account and the public documentation.

Two points on environment. A staging copy is a reasonable target only if its authentication, gateway and authorization configuration match production; otherwise test production with seeded accounts and agreed limits. And grey-box testing, with accounts and documentation, is the default for APIs. A black-box test that never signs in reaches the login page and the public endpoints and stops there. Our guide to black-box, grey-box and white-box penetration testing explains the trade-off.

The checklist: OWASP API Security Top 10 2023, mapped to test activities

The OWASP API Security Top 10 2023 is the second edition of the list and, as of 13 November 2026, still the version the project page lists as latest. Its release notes call it "a forward-looking awareness document" and say plainly that "It does not replace other TOP 10's." It is a list of risks, not a test procedure, so a checklist has to translate each risk into something a tester does and something a report can show.

OWASP scores each risk on exploitability, prevalence, detectability and technical impact. The ratings are worth reading before a kickoff, because they show where the list expects problems to be common and where it expects them to hide.

Figure 2: OWASP's ratings for each risk in the API Security Top 10 2023. Source: OWASP API Security Top 10 2023.

Five of the ten are rated Widespread, and nine of the ten are rated Easy to exploit. Three (API6, API9 and API10) have Average detectability, and all three depend on information only the owner has: which flows are sensitive, which hosts exist, and which services the API trusts. That is the argument for the preparation table above.

The sections below expand each row. For test method detail, the development version of the OWASP Web Security Testing Guide, the content being prepared for release 5.0, has an API testing chapter (WSTG-APIT-01 to 04, plus GraphQL). The stable release, v4.2, covers only GraphQL under API testing and numbers that test WSTG-APIT-01, so every WSTG-APIT ID in this checklist refers to the development version. OWASP ASVS 5.0 gives numbered requirements a report can cite.

API1:2023 Broken Object Level Authorization (BOLA)

OWASP's rule is that every endpoint that "receives an ID of an object, and performs any action on the object, should implement object-level authorization checks." This is the flaw web developers call IDOR, and it gets its own guide: our IDOR vulnerability post covers documented cases, the test method and the fixes, so this checklist keeps to the items to tick.

• Every endpoint that takes an object identifier is replayed under a second user with the same role, a user with a different role, a user in another tenant and a signed-out caller.

• Every operation is covered, not only reads: update, delete, export, bulk actions and list filters.

• Identifiers are tested wherever they sit: path, query string, headers, request body, GraphQL variables and node IDs.

• Random identifiers such as UUIDs get the same treatment as sequential ones.

Evidence to expect: the identities-against-endpoints grid described in our API authorization test matrix, mapped to ASVS 5.0 requirements 8.2.2 (object-level access) and 8.4.1 (cross-tenant controls).

API2:2023 Broken Authentication

OWASP's advice starts with a blunt reminder: "OAuth is not authentication, and neither are API keys." It also says password reset "should be treated the same way as authentication mechanisms."

• Every authentication path is listed and tested: login, single sign-on, password reset, MFA enrolment and recovery, token refresh, API keys and service-to-service credentials.

• Login, reset and one-time-code endpoints resist credential stuffing and brute force, tested inside the limits agreed in preparation.

• Tokens are validated properly: signature, permitted algorithm, expiry, issuer and audience.

• Logout, password change and role downgrade end access for tokens already issued.

• Changing an email address or MFA phone number requires re-authentication.

• Internal services do not accept unauthenticated calls from each other.

Evidence to expect: a result for each flow, and for each token test the altered token and the server's response.

API3:2023 Broken Object Property Level Authorization

This category merged two entries from the 2019 list, Excessive Data Exposure and Mass Assignment, around one root cause: authorization at the level of individual fields.

• API responses are compared with what the interface displays, for each role, to find fields the client hides but the server still sends (the Excessive Data Exposure test, WSTG-APIT-03 in the development version).

• Write requests are replayed with properties the client never sends, such as a role, a price, an owner or a verification flag, to see whether the server binds them.

• Nested and embedded objects are inspected, since a safe parent often embeds an unsafe child.

• In GraphQL, fields are requested beyond those the client uses.

Evidence to expect: the specific fields exposed or accepted, per role, mapped to ASVS 5.0 requirement 8.2.3 (field-level access).

API4:2023 Unrestricted Resource Consumption

OWASP lists the limits whose absence makes an API vulnerable, including execution timeouts, maximum upload size, records per page, the number of operations in a single request and third-party spending limits.

• Pagination and page-size parameters accept only bounded values.

• Payload size, upload size, array length and string length are capped.

• Rate limits exist per user or per key, not only in total, and excess requests receive a 429 response.

• GraphQL batching and aliases cannot multiply an operation past the limit.

• Operations that trigger paid third-party calls, such as SMS and email, are throttled per user and capped by a spending limit or billing alert.

A penetration test demonstrates the missing limit at low volume. It does not take the service down to prove a point, and load-based denial of service belongs in scope only by explicit agreement.

Evidence to expect: the measured limit, or the lack of one, for each endpoint tested, mapped to ASVS 5.0 requirement 2.4.1 (anti-automation).

API5:2023 Broken Function Level Authorization

Where BOLA is about which object, this risk is about which function. OWASP warns: "Don't assume that an API endpoint is regular or administrative only based on the URL path."

• Every administrative and privileged function is called with a regular user's token and with no token (the API Broken Function Level Authorization test, WSTG-APIT-04 in the development version).

• The HTTP method is changed on known paths, for example from a read to a delete.

• Privileged functions that live outside the obvious admin path are found and tested.

• Intermediate roles are tested against each other: support staff, read-only users, sub-users and partner roles.

• Administrative routes in older API versions get the same checks.

Evidence to expect: a matrix of roles against functions, mapped to ASVS 5.0 requirement 8.2.1.

API6:2023 Unrestricted Access to Sensitive Business Flows

This is the entry a scanner is least equipped to judge, because, as OWASP puts it, the risk "doesn't necessarily come from implementation bugs." Each request is valid. The harm comes from doing it a thousand times, or out of order.

• Each flow named in preparation is automated end to end at a modest rate, to see which control stops it and when.

• Steps are skipped, repeated and reordered: a coupon applied twice, a checkout completed without payment confirmation, a referral credited repeatedly.

• Limited resources such as seats, stock and appointment slots cannot be held or double-booked.

• Anti-automation controls on the website also hold when the API is called directly, through the mobile backend or through an older version.

Evidence to expect: a description of what was achieved in business terms, mapped to ASVS 5.0 requirements 2.3.1 (step order) and 2.3.4 (limited-quantity resources).

API7:2023 Server Side Request Forgery (SSRF)

OWASP names the features that make SSRF more common in APIs: "Webhooks, file fetching from URLs, custom SSO, and URL previews."

• Every parameter that accepts a URL or hostname is identified, including webhook targets, import-from-URL features, image and document fetchers and SSO metadata.

• The tester checks whether the server can be made to call internal addresses or cloud metadata services, and whether it follows redirects to them.

• Blind cases, where no response comes back, are checked with a listener the tester controls.

• Raw upstream responses are not relayed to the caller.

Evidence to expect: the destination reached and proof that stops short of harvesting data or credentials beyond what the rules of engagement allow.

API8:2023 Security Misconfiguration

• TLS is enforced on every host, including internal and partner endpoints.

• The CORS policy does not trust arbitrary origins with credentials.

• Unused HTTP methods are refused.

• Error responses do not include stack traces, queries or internal hostnames.

• Default credentials, sample applications and debug or actuator endpoints are absent.

• Gateways, load balancers and application servers interpret a request the same way.

• Components are patched.

This is the part of the checklist where automated tooling does most of the work, and a good report still shows the request behind each entry instead of a scanner export.

Evidence to expect: one entry per misconfiguration with the request that reveals it.

API9:2023 Improper Inventory Management

OWASP's description includes a sentence that explains many breaches: "Sometimes different API versions/deployments are connected to the same database with real data."

• Endpoints and parameters are discovered beyond the specification, from client-side code, mobile application traffic, old documentation and archived pages. The API Reconnaissance test in the development version of the WSTG (WSTG-APIT-01 there) sets the objective: find all endpoints, "documented or undocumented."

• Older versions and beta, staging and regional hosts are checked for the same authentication, authorization and rate limits as the current production version.

• Interactive documentation for internal APIs is not publicly reachable.

Evidence to expect: the inventory the tester discovered, set against the one you provided. The differences are findings in their own right.

API10:2023 Unsafe Consumption of APIs

OWASP observes that "Developers tend to trust data received from third-party APIs more than user input."

• Data returned by upstream services is validated before it is stored, rendered or passed on.

• Redirects from upstream services are not followed blindly.

• Outbound calls use TLS, and timeouts and size limits apply to upstream responses.

• Inbound webhook handlers verify the sender (see the next section).

Testing uses the vendor's sandbox or a simulated upstream. Our third-party API integration penetration testing guide covers where the authorization line sits.

Evidence to expect: the integrations tested and how upstream behaviour was simulated.

Beyond the Top 10: tokens, API keys, rate limits, GraphQL, webhooks and injection

The Top 10 is an awareness list, and two entries from the 2019 edition, Injection (API8:2019) and Insufficient Logging & Monitoring (API10:2019), do not appear in the 2023 edition at all. Both still belong in a test. So do the components that the ten risks mention only in passing.

Tokens. RFC 8725, the IETF's best current practice for JSON Web Tokens, was published in February 2020 and remains the reference. Its requirements are specific enough to test: a library must use only the algorithms the application has specified, so a token cannot choose how it is verified, and where one issuer serves several applications, a token whose audience is missing or names another recipient must be rejected. ASVS 5.0 turns these into numbered requirements a report can cite: signature, algorithm allowlist and key source (9.1.1 to 9.1.3) and expiry (9.2.1) at Level 1, and audience (9.2.3) at Level 2.

OAuth. RFC 9700, published in January 2025, is the current OAuth 2.0 security best practice. It says the resource owner password credentials grant "MUST NOT be used", that clients should not use the implicit grant, and that authorization servers must compare redirect URIs by exact string matching, with one narrow exception for native applications. A tester checks which grants the authorization server still accepts, not which ones the documentation says the product uses.

API keys. OWASP is direct: "API keys should not be used for user authentication." A key identifies a client application. Testers check what a key can reach, whether a low-privilege key can call high-privilege operations, and whether keys turn up in places they should not. Our guide to leaked API keys and non-human identities collects the published figures on how often they do.

Rate limits. RFC 6585 defines the 429 status code for a client that "has sent too many requests in a given amount of time." NIST SP 800-228, finalized in June 2025 and updated on 13 March 2026, adds the design rules a tester checks against: "Rate limits are not quotas", and limits should be dimensioned by user, because a limit on total load lets one caller starve the rest. ASVS 5.0 requirement 4.1.3 covers the common bypass, where a client overrides a forwarding header that the gateway trusts to identify the caller.

GraphQL. A single GraphQL endpoint can hold the whole Top 10, and its query language adds its own problems. ASVS 5.0 asks that introspection be disabled in production "unless the GraphQL API is meant to be used by other parties" (4.3.2) and that a query allowlist, depth limiting, amount limiting or query cost analysis be in place (4.3.1). Authorization has to be tested resolver by resolver. Our GraphQL API vulnerabilities guide covers the classes in detail.

Webhooks. A webhook receiver is an unauthenticated public endpoint until it verifies its sender. GitHub's documentation tells receivers to validate the HMAC signature with a constant-time comparison, and Stripe's documentation describes a signed timestamp, with a default tolerance of five minutes in its libraries, to defeat replays. A tester sends unsigned, wrongly signed and replayed events and expects each to be refused. On the sending side, a customer-supplied webhook URL is an SSRF input and is tested as one. Platform-specific scoping is covered in our GitHub App penetration testing guide.

What the API penetration test report should show

A report that lists findings and nothing else leaves the buyer unable to tell a clean API from an untested one. Check the report against this list before accepting it.

• Scope as tested. Hosts, versions and environments, test dates, test type (grey box or otherwise), and anything that limited testing.

• Identities used. Which roles and tenants the tester held, and which account created which test objects.

• Coverage for each of the ten OWASP API risks. Tested, not applicable, or not tested, with the reason.

• Evidence for every finding. The endpoint, the identity, the request and response, the expected and actual result, and the impact stated as data or function exposed.

• Severity with reasoning. A rating tied to what is behind the endpoint, not only to the vulnerability class.

• Remediation a developer can act on. The fix at the code, gateway or configuration level, with the OWASP API risk, CWE and ASVS requirement it maps to.

• What passed. Controls that held, such as the cross-tenant checks that returned a refusal.

• Discovered inventory. Endpoints and hosts found that were not in the material you supplied.

• Retest results. Each fixed finding re-run, with the date and outcome, in the final version.

Two companion guides go further: how to evaluate a penetration test report and the OWASP ASVS 5.0 pentest acceptance matrix, which shows how to write requirement numbers into a statement of work.

The one-page version

For a kickoff call or a statement of work, the checklist compresses to this.

Prepare

• An inventory of API hosts, environments and versions, and a specification for each.

• A role and permission matrix, two accounts per role, an administrator, and a second tenant.

• A list of sensitive business flows, and agreed limits for rate-limit, lockout and load checks.

• Sandboxes for third-party integrations and test secrets for webhooks.

Test

• Object, property and function level authorization, across every role and tenant, for every operation (API1, API3, API5).

• Every authentication flow, token validation and token lifecycle (API2).

• Resource limits and abuse of sensitive business flows (API4, API6).

• SSRF, misconfiguration, undocumented hosts and versions, and third-party trust (API7 to API10).

• Tokens, OAuth, API keys, GraphQL, webhooks, injection and detection.

Expect

• Scope, identities and coverage for each of the ten risks.

• The request and response behind every finding, and a list of what passed.

• A retest of every fix, recorded in the final report.

Scoping and cost: what drives an API penetration test

Endpoint count is the number many quotes are built on, and it is a weak predictor of effort. Twenty endpoints with five roles, two tenant models and a payment flow can take longer to test properly than two hundred read-only endpoints behind one role. The inputs that drive effort are the ones in the preparation table: roles, tenants, authentication flows, sensitive business flows and integrations. Our API penetration testing cost guide shows how to compare API-only and bundled quotes on those terms, and the general method is in how to scope a penetration test.

Five questions separate providers quickly:

1. How many accounts and tenants will you test with, and will the report list them?

2. Will the report show coverage for each OWASP API Security Top 10 2023 risk, including what passed?

3. How do you discover endpoints that are not in our specification?

4. How do you test rate limits and business flows without disrupting production?

5. Is a retest of fixed findings included, and are its results written into the final report?

For a comparison of firms against questions like these, see our ranking of the best API penetration testing companies.

How Stingrai tests APIs

Stingrai is a CREST-accredited penetration testing company offering fully human-led and hybrid (human penetration testers plus AI agents) penetration tests, delivered by experienced penetration testers who are also world-class security researchers and bug bounty hunters. Its API penetration tests are authenticated across every user role and cover REST and GraphQL, broken authorization and IDOR, authentication and session handling, business logic and injection, aligned to the OWASP API Security Top 10 and ASVS and source-assisted where repository access is given. The team has 18 published CVEs.

Each human-led engagement is staffed by two named penetration testers from a team holding OSCE³, OSWE, OSEP and CREST CRT certifications. Findings are posted to the PTaaS portal as they are confirmed, each with a working proof of concept and prioritized remediation guidance, and retesting of remediated findings is included. Engagements run as one-time (annual) tests or as continuous programs.

For one web application and associated APIs, published pricing is fixed. The Autonomous Pentest, run by Snipe, Stingrai's autonomous AI agent for web applications and associated APIs, is US$3,000 per assessment or US$650 per month on a 12-month plan, and covers up to 200 API endpoints or dynamic pages and up to three user roles. The Hybrid Pentest, where penetration testers and Snipe test together throughout, is US$6,800 per assessment or US$1,275 per month. Standalone APIs, several products behind one gateway and larger estates are quoted per engagement. Details are on the pricing page.

Frequently Asked Questions

What is an API penetration testing checklist?

An API penetration testing checklist is a list of what must be prepared, tested and reported for an API penetration test to be complete. The preparation part covers the API inventory, a specification, accounts for every role and a second tenant. The testing part follows the ten risks of the OWASP API Security Top 10 2023 and adds token handling, API keys, GraphQL, webhooks and injection. The reporting part lists the evidence a buyer should receive, including coverage for each risk and the retest results.

What should an API penetration test cover?

At minimum, the ten risks in the OWASP API Security Top 10 2023: object, property and function level authorization, authentication, resource consumption, sensitive business flows, server side request forgery, misconfiguration, inventory and unsafe consumption of third-party APIs. A complete test also covers token validation, OAuth configuration, API keys, GraphQL limits, webhooks and injection, and it tests every role and tenant across every version of the API that still responds.

What is the difference between API security testing and API penetration testing?

API security testing is the umbrella term for every way of checking an API, including specification review, static analysis, dynamic scanning and fuzzing. API penetration testing is one method within it, in which a tester or a purpose-built agent uses real identities to try to break the API's rules and proves the impact. Scanners are good at misconfiguration and known patterns. A penetration test is how authorization across roles and tenants and abuse of business flows get checked.

Is the OWASP API Security Top 10 2023 still current in 2026?

Yes. The 2023 edition was released as a stable version on 5 June 2023 and is the second edition of the list, following the 2019 first edition. As of 13 November 2026 the OWASP project page still lists 2023 as the latest version. OWASP describes it as an awareness document that does not replace its other Top 10 lists, so a test should use it alongside the Web Security Testing Guide and ASVS 5.0.

What do I need to prepare for an API penetration test?

Prepare an inventory of API hosts, environments and versions, a specification such as an OpenAPI file or GraphQL schema, a role and permission matrix, two accounts for each role plus an administrator, a second tenant for multi-tenant products, a list of sensitive business flows, agreed limits for rate-limit and lockout testing, and sandbox access for third-party integrations. Seed each account with its own test data so that no customer data is touched.

Can a vulnerability scanner or DAST tool replace an API penetration test?

No. Scanners find misconfiguration, known vulnerable components and many input handling flaws, and they belong in the build pipeline. They have no model of who owns which object, so they rarely find broken authorization on their own. CISA, the NSA and the Australian Cyber Security Centre state that not all DAST tools can detect IDOR vulnerabilities. Four of the first five OWASP API risks are authentication or authorization failures, which is where a penetration test spends most of its time.

Does an API penetration test cover GraphQL and webhooks?

It should, and both are worth naming in the scope. GraphQL needs its own checks: introspection in production, query depth and cost limits, batching and aliases, and authorization in every resolver. Webhooks need checks in both directions: receivers must verify signatures and reject replays, and any feature that lets a customer supply a webhook URL is tested for server side request forgery.

What should an API penetration test report include?

The report should state the hosts, versions and environments tested, the roles and tenants used, and coverage for each of the ten OWASP API risks. Every finding should include the endpoint, the identity, the request and response, the impact and a fix a developer can act on. It should also record the checks that passed, any endpoints discovered outside the supplied inventory, and the dated retest result for each fixed finding.

How much does an API penetration test cost?

It depends on roles, tenants, authentication flows, business flows and integrations more than on endpoint count. As a published reference, Stingrai's Autonomous Pentest is US$3,000 and its Hybrid Pentest is US$6,800 per assessment for one web application and associated APIs. Standalone APIs and larger estates are quoted per engagement.

An API test is easiest to buy well when the checklist is agreed before the quote. To go through it against your own APIs, book a 30-minute scoping call or get a quote.

Related reading

• IDOR Vulnerability: Real Examples, How Testers Find It and How to Fix It

• API Authorization Test Matrix 2026: What a Buyer Should Ask to See

• API Penetration Testing Cost in 2026: Compare API-Only and Bundled Quotes

• Best API Penetration Testing Companies (2026)

• Why Automated API Scanners Miss BOLA and IDOR

• GraphQL API Vulnerabilities and Common Attacks: A Technical Guide

• Third-Party API Integration Penetration Testing: Buyer Scope (2026)

• Multi-Tenant SaaS Penetration Test Scope: A Buyer Guide

• OWASP Mobile Top 10 (2024): What Each Risk Means and How a Penetration Test Checks It

• OWASP Top 10 2025: The Full List, What Changed and How to Test Each Risk

• Cross-Site Scripting (XSS): Real Examples, How Testers Find It and How to Fix It

• Best Mobile App Penetration Testing Companies (2026): 7 Compared for Security Leads

• Web Application Penetration Testing: What It Is, What It Tests and How It Works (2026)

• Best Web Application Penetration Testing Companies (2026): Services Compared

References

1. OWASP. API Security Top 10 2023, with the release notes and the individual risk pages API1:2023 to API10:2023.

2. OWASP. API Security Project, project page and news.

3. OWASP. API Security Top 10 2019.

4. OWASP. Web Security Testing Guide, 4.12 API Testing (development version, in preparation for release 5.0).

5. OWASP. Application Security Verification Standard 5.0, chapters V2, V4, V8, V9 and V10.

6. OWASP. REST Security Cheat Sheet and GraphQL Cheat Sheet.

7. OWASP. Top 10:2025.

8. NIST. SP 800-228, Guidelines for API Protection for Cloud-Native Systems, June 2025 (updated 13 March 2026).

9. IETF. RFC 8725, JSON Web Token Best Current Practices, February 2020.

10. IETF. RFC 9700, Best Current Practice for OAuth 2.0 Security, January 2025.

11. IETF. RFC 6585, Additional HTTP Status Codes, April 2012.

12. CISA, NSA and ACSC. Preventing Web Application Access Control Abuse (AA23-208A), 27 July 2023.

13. T-Mobile US, Inc. Form 8-K, 19 January 2023.

14. GitHub. Validating webhook deliveries.

15. Stripe. Receive Stripe events in your webhook endpoint.

16. Stingrai. State of Penetration Testing 2026.