Checklist

API pentesting checklist for SaaS and software teams

By Lucas Weber, CyberSec42 · Updated 28 Oct 2026

An API pentest checks whether your interface only returns and only executes what each account is allowed to. It centres on the risks in the OWASP API Security Top 10, currently the 2023 edition: above all broken authorization at object, property and function level, plus missing limits, server-side request forgery and trusting third-party APIs too readily. The single most important test fits in one sentence: with two accounts in two tenants, swap every object ID from one into a request carrying the other's token, and not one request may succeed.

Why APIs are the main target

In a SaaS product, the user interface is just one client among several. The web front end, the mobile app and customer integrations all talk to the same API, and whatever the interface hides, the API may still return. An attacker opens the browser's developer tools, sees the requests with their IDs and tokens, and replays them with changes. No known library vulnerability is required.

That is why the typical API weaknesses are not exotic coding bugs but gaps in business logic:

• Object level authorization (BOLA). The API checks that someone is logged in, but not that the requested object belongs to them. OWASP ranks this as risk number one.
• Function level authorization. A regular account reaches admin functions because the check lives only in the front end, or because a different HTTP method was left unprotected.
• Mass assignment. The API copies fields from the request straight into the data object, including fields such as role or tenant.
• Server-side request forgery (SSRF). The API fetches a URL supplied by the user, for webhooks or link previews, and can be steered towards internal services.
• Missing limits. Without caps on requests, page sizes or paid follow-up actions such as sending SMS, abuse and cost become a risk.
• Unsafe consumption of third-party APIs. Data from payment providers, CRMs or AI services is often treated as trusted and validated less strictly than user input.

For SaaS vendors, the first item weighs heaviest. If one customer can read another customer's data through the API, the trust promise of the whole platform is broken.

The OWASP API Security Top 10 (2023 edition)

Alongside its well-known Top 10 for web applications, the Open Worldwide Application Security Project (OWASP) publishes a separate list for APIs. The first edition appeared in 2019, the current second edition in 2023. No newer edition has been published on the project site as of 28 October 2026. According to the release notes, no data was contributed for the 2023 edition; the list rests on the project team's experience, review by API security specialists and community feedback. It is an awareness document, not a testing standard with a pass mark.

Compared with 2019, OWASP merged "Excessive Data Exposure" and "Mass Assignment" into API3, because both share a root cause: missing authorization at the level of individual properties. API6 and API10 are new in 2023.

How an API pentest works

We cover the general flow of a penetration test, from sign-off to retest, in a separate article: Penetration testing: process, duration and cost. This section is about what is different with APIs. Three things decide how meaningful the test will be.

Scope: specification and inventory

The starting point is an up-to-date description of the interface, usually an OpenAPI specification (formerly Swagger), or the schema for GraphQL. It lists every endpoint, parameter and expected response, which makes the test plannable. Just as important is what the specification leaves out. Under API9, OWASP explicitly names old versions, forgotten hosts and missing documentation as a risk. So agree in writing:

• which hosts and versions are tested, for example api.example.com/v2, and whether /v1 is still reachable,
• which endpoints are excluded and why, such as payment execution or bulk messaging,
• which connected third-party services may be touched and which may not,
• who can be reached during the test if something goes wrong.

Roles and test accounts per tenant

Without the right test accounts, an API pentest stays on the surface. A multi-tenant application needs at least two separate tenants, one account per relevant role in each, and real test data in each account, meaning created objects such as projects, invoices or documents. Only then can you check whether tenant A reaches tenant B's objects and whether a basic role reaches the functions of a higher one.

Environment

A staging environment that matches production in code, configuration and upstream components such as the API gateway and web application firewall works best. If it differs, the test examines a different system. Under API9, OWASP advises against using production data in non-production environments and, where that cannot be avoided, protecting them like production. Payment, email and SMS providers should run in test mode so that checks for API4 and API6 do not trigger real costs or messages.

A note for anyone testing in-house: only test systems for which the operator has given written authorization. That includes connected third-party APIs you do not own.

The test steps in detail

The following steps follow the OWASP API Security Top 10 and the "API Testing" chapter of the OWASP Web Security Testing Guide. The example paths are made up and stand for patterns found in many APIs.

1. Object access: swap IDs between tenants (API1)

The most important single test. Account A creates an object, say an invoice. The same request is then sent with account B's token:

GET /api/v2/invoices/8f3c… with Authorization: Bearer <B-User token>

• Expected: 403 or 404. A 200 carrying A's data is a finding.
• Every method. Not just reads, but also PUT, PATCH and DELETE on someone else's objects. An endpoint that checks on read but not on delete is not unusual.
• IDs everywhere. IDs appear in the path, query parameters, JSON body, headers and GraphQL queries. Each location is swapped separately.
• Lists and filters. Endpoints such as GET /api/v2/invoices?customer_id=… or exports often return whole data sets. Check that the filter stays within your own tenant.
• Random IDs are not a control. UUIDs make guessing harder, but IDs leak through links, emails, logs and other responses. OWASP recommends them as an addition, not as a replacement for a per-object check.

2. Properties and mass assignment (API3)

• Read the responses. Does GET /api/v2/users/me contain fields the user should not see, such as internal flags, hashes or other people's data? The front end may hide them; the API still sends them.
• Add fields. Extend an update such as PATCH /api/v2/users/me with fields like "role": "admin", "tenant_id": "…" or "plan": "enterprise". If the API accepts them, that is mass assignment.

3. Function level: roles and methods (API5)

• Call admin functions with a basic account. Send A-User's token to endpoints only administrators use, such as inviting users, changing roles or exporting all data.
• Switch the method. If GET /api/v2/users/42 is allowed, what happens with DELETE on the same path?
• Don't trust the path. OWASP points out that admin functions often do not sit under /admin but alongside regular endpoints.
• Without a token. Call every endpoint once with no authentication at all.

4. Authentication and tokens (API2)

• Are token signatures validated? Does the API accept a JWT with "alg": "none" or an expired token?
• Are login, password reset and one-time codes protected against mass guessing?
• Do tokens or passwords appear in URLs, where they end up in logs?
• Do sensitive changes such as email address or password require re-confirmation?

5. Limits and sensitive flows (API4, API6)

• Page size. Does ?limit= accept arbitrarily large values? A single request can then pull entire tables and load the database.
• Repeated actions. How often can a one-time code be checked, a password reset requested or an invitation sent?
• Paid follow-up actions. Do requests trigger SMS, emails or calls to paid services? OWASP recommends spending limits with the provider, or at least billing alerts.
• Business flows. Can a flow be abused through automation, such as booking every slot or mass-creating trial accounts? This is not a coding bug but a missing limit.

6. Server-side request forgery (API7)

Wherever the API fetches a user-supplied URL, for example webhook targets, import by link, image from URL or link previews:

• Supply internal targets: localhost, private address ranges and the cloud environment's metadata services.
• Test redirects: an allowed external URL that redirects to an internal target. OWASP recommends disabling redirects when fetching.
• Try other schemes and ports, and check whether the target's raw response is passed back to the user.

7. Configuration and inventory (API8, API9)

• Error messages without stack traces or internal paths, TLS throughout, CORS limited to your own origins.
• Older versions such as /v1 switched off or protected exactly like the current one.
• Staging, test and debug endpoints not publicly reachable.

8. Third-party APIs (API10)

• Data from connected services is validated like user input before it reaches the database, templates or downstream systems.
• Encrypted connections only, no blind redirect following, timeouts and response size limits in place.
• Webhooks from third parties are checked for a valid signature before the API processes them.

The checklist

What automated scanners find, and what they miss

API scanners and fuzzers are useful, and a good test uses them. They work through the specification, send altered input and compare responses against known patterns. That reliably covers one class of flaws. Authorization logic is not part of it.

The reason is simple: a 200 with data looks correct to a scanner. Whether that data belongs to the requesting account is not in the response; it is in your application's business rules. Only someone who knows which account belongs to which tenant, and who cross-checks the request with two accounts, can judge it. OWASP says as much for function level flaws: the best way to find them is a deep analysis of the authorization mechanism with the role and group hierarchy in mind. For how an automated vulnerability assessment differs from a penetration test overall, see Vulnerability assessment: what it is and when you need one.

For your engineering team, there is a practical upside: the swap test from step 1 can become an automated test in your own pipeline. OWASP recommends writing tests for the authorization mechanism and not shipping changes that make them fail. The pentest finds the gaps; the regression test keeps them from coming back.

What the report should contain

An API pentest report is useful when your engineers can reproduce every finding without asking. For each finding it should include:

• Affected endpoint and method, with version and host.
• The exact request and response as evidence, stating which test account from which tenant was used.
• Impact in plain words, such as "tenant B can read and delete tenant A's invoices", not just a category.
• Severity rating using a transparent method such as CVSS, with reasoning.
• Mapping to the OWASP category, so findings can be matched against questionnaires and internal policies.
• A concrete fix, ideally pointing to the place in code or configuration where it belongs.

Add a management summary, the coverage (which endpoints and roles were tested and which were not) and a retest of the fixes.

API pentest or SaaS pentest?

For many SaaS products the API is the largest part of the attack surface, but not the only one. Tenant isolation also concerns file storage, background jobs, search indexes, exports and support access. If your goal is to show an enterprise customer that no tenant can see another tenant's data, a SaaS penetration test focused on tenant isolation is the right frame, with the API review at its core. For a public or partner API without its own interface, an API pentest on its own is often enough.

Frequently asked questions

Further reading

• OWASP Top 10 2025 explained
• Lovable Security Issues: What Is Documented and How to Fix Them
• Penetration Testing: Process, Duration and What It Costs
• Vulnerability Assessment: what it is and when you need one
• MCP and OAuth: Securing the Trust Anchor
• Service: SaaS penetration testing focused on tenant isolation

Sources

• OWASP API Security Top 10 2023: overview of the ten risks
• OWASP API Security Top 10 2023: release notes
• OWASP API1:2023 Broken Object Level Authorization
• OWASP API5:2023 Broken Function Level Authorization
• OWASP API7:2023 Server Side Request Forgery
• OWASP Web Security Testing Guide: API Broken Object Level Authorization
• OWASP Web Security Testing Guide: API Broken Function Level Authorization
• OWASP API Security Project on GitHub (2019 and 2023 editions)