Penetration Test Servicesby Excession Labs Request a test

API penetration testing

API penetration testing for REST and GraphQL APIs, mapped to the OWASP API Security Top 10 2023. Proven findings, a written report and fix guidance.

Short answer

API penetration testing checks whether your REST or GraphQL API enforces who can read and change what. We test against the OWASP API Security Top 10 2023: object-level and function-level authorization, mass assignment, rate limits, business flows and inventory. Each finding comes with request and response evidence, controls and fix guidance in a written report.

Mobile apps, single-page apps and partners all call your API, and each call assumes the server decides who may do what. API penetration testing checks that the server enforces that on every route, including routes the front end never calls.

What do we test in an API?#

We organize the work around the OWASP API Security Top 10 2023. We add business-specific checks that the list cannot name.

OWASP item Question we answer
API1 Broken Object Level Authorization Can user A read or change user B's invoice by changing an ID?
API2 Broken Authentication Do login, token refresh, password reset and API keys resist abuse?
API3 Broken Object Property Level Authorization Does the API return fields a user should not see? Can a user set fields such as role or plan in a write request?
API4 Unrestricted Resource Consumption Are rate, size, pagination and cost limits set and enforced?
API5 Broken Function Level Authorization Can a normal user call an admin or internal route?
API6 Unrestricted Access to Sensitive Business Flows Can a script abuse sign-up, checkout or invitations at scale?
API7 Server Side Request Forgery Can a URL parameter make the server fetch an internal resource?
API8 Security Misconfiguration Do CORS, errors, verbs and headers expose more than needed?
API9 Improper Inventory Management Do old versions, debug routes or undocumented endpoints remain live?

OWASP says attackers exploit BOLA "by manipulating the ID of an object that is sent within the request" (API1:2023). So we test with two accounts and swap identifiers. API3 covers what older lists called mass assignment: a user able "to change, add/or delete the value of a sensitive object's property which the user should not be able to access" (API3:2023). For more, see our guide to IDOR and BOLA testing and the API Top 10 test ideas.

For REST we test every verb on every route. For GraphQL we test authorization per resolver, query depth and cost, batching and introspection.

How do we prove API findings?#

A finding needs a real effect, and a response code does not show one. We prove a write by reading the record back through a second session. We run controls beside each exploit request: a nonexistent ID, the wrong record type, another account's token, and an anonymous call. Controls that held are reported too. The methodology states the full standard.

We bound rate-limit and abuse tests. API4:2023 says an API is vulnerable if limits are missing or set inappropriately. We agree volumes in scope, use test-owned accounts and state the cost of paid third-party calls in the report.

Sample finding

This is a demonstration. It uses a fictional app, Harbor Notes, and no real customer system was tested.

Finding A-04: A user can set their own plan through a profile update (High). The API accepts a property the client should not control (API3:2023).

Request as a free-plan user:

PATCH /api/v1/me HTTP/1.1
Host: api.example.com
Authorization: Bearer <free-user-token>
Content-Type: application/json


{"display_name":"Test A","plan":"enterprise"}

Response, then a read-back through a second session (Observed):

HTTP/1.1 200 OK
{"display_name":"Test A","plan":"enterprise"}

Control: the same request with "role":"admin" was rejected with 403. That control held. Fix: use an allow list of writable fields on this route.

What do you get?#

The report comes in HTML, PDF and Markdown, with proof-of-concept scripts. Each finding has a description, impact, verified results, reproduction steps and remediation. The report also has an executive summary, a findings table, a remediation plan and an evidence index. We save requests and responses with timestamps. We can retest fixes; see retesting.

What do we need from you?#

  • Written authorization and the base URLs in scope.
  • An OpenAPI file, Postman collection or GraphQL schema, if you have one.
  • Test accounts for each role, and for at least two tenants or users.
  • How tokens are issued, how long they live, and how API keys work.
  • Any rate limits, WAF rules or bot protection that may block tests.
  • A contact who can read logs during the test.

What changes the quote?#

Effort depends on the number of routes or operations, roles, tenants and auth schemes, and on documentation quality, the environment and the retest. GraphQL schemas with many types take longer. We publish no prices and quote after scoping; see pricing.

Ready to scope an API test? Request a pentest.

Questions

Do you need our API documentation?

It helps a lot. An OpenAPI file, a Postman collection or a GraphQL schema shortens discovery. Without them we map the API from the app and its JavaScript. Hidden or undocumented routes are a common finding, so we test those too.

Do you test GraphQL?

Yes. We check authorization on each resolver, query depth and cost limits, batching, and whether introspection exposes more than you intend. Introspection alone is not a finding. We report what an attacker can do with it.

How do you test rate limits without harming production?

We bound the test. We agree the volume and target in scope, use test-owned accounts, and state the cost of any paid third-party calls in the report. Password guessing and email sending are limited in the same way.

Do you test internal or partner APIs?

Yes, if they are in the written scope and you can give us credentials and an environment. Say who consumes the API during scoping. Partner tokens and service-to-service calls often have different authorization rules.

Sources

  1. OWASP API Security Top 10 2023 (checked 9 November 2026)
  2. OWASP API1:2023 Broken Object Level Authorization (checked 9 November 2026)
  3. OWASP API3:2023 Broken Object Property Level Authorization (checked 9 November 2026)
  4. OWASP API4:2023 Unrestricted Resource Consumption (checked 9 November 2026)
PageWeb application penetration testing: what we test and proveWeb application penetration testing, black box or grey box: the eight areas we test, a sample finding with evidence, and the written report you receive.PageSaaS penetration testing for multi-tenant productsSaaS penetration testing for multi-tenant products: eight areas we test, the two-tenant method, a sample finding, and what the report contains.API testingOWASP API Security Top 10 (2023): the list and how to test each riskThe OWASP API Security Top 10 2023 list with exact IDs from API1 to API10, plus test ideas, sample requests, a test-case table and the usual fix for each risk.API testingIDOR testing: how pentesters find broken object-level authorizationIDOR testing step by step: prove it with two accounts and a read-back, use a 7-case test table and demo requests, and fix BOLA with a server-side check.PageSample penetration testing report for a fictional appA full sample penetration testing report for a fictional SaaS app: scope, method, nine findings with requests and evidence, controls that held, and a fix plan.

Need a pentest you can act on?

Tell us what you need tested and why. We reply to agree scope, and testing starts only after written authorization.

Request a testSee the sample report