Application testing

API Penetration Testing

We test every endpoint your product depends on, by hand, and show you which ones an attacker could turn against you.

  • OWASP API Security Top 10
  • OWASP WSTG

Overview

APIs are now the product. They power your web app, your mobile app, your integrations and your partners. They also hand attackers a direct, structured way into your data. Most serious API flaws aren’t exotic. They are missing checks: an endpoint that returns any record you ask for, or accepts fields it should ignore.

Scanners struggle here because they don’t understand who should be allowed to do what. Our testers do. We test each endpoint with accounts for every role and tenant, look for gaps between what the API should allow and what it actually allows, and give you evidence your engineers can reproduce in minutes.

Scope

What we test

  • Object-level authorization (BOLA / IDOR) on every resource
  • Function-level authorization between roles and scopes
  • Authentication and token handling, including JWT and OAuth 2.0
  • Mass assignment and over-posting of hidden fields
  • Excessive data exposure in responses
  • Rate limiting, quotas and resource consumption
  • Input validation and injection across all parameters
  • GraphQL introspection, query depth and batching abuse
  • gRPC and protobuf services where applicable
  • Versioning, deprecated and shadow endpoints
  • Webhook delivery, signing and replay protection
  • Server-side request forgery through URL parameters
  • CORS and transport configuration

Findings

Common issues we find

Generic examples of what this kind of testing tends to uncover. Every engagement is different, and we never share client findings.

Critical

Any user can read any record by changing an ID

The API checks that a token is valid, but not that the requested object belongs to its owner.

High

Users can promote themselves

A profile update endpoint accepts role or plan fields it was never meant to accept.

High

Responses leak more than the client shows

Full user objects, internal flags or other customers' details returned and filtered only in the front end.

High

Weak JWT validation

Tokens accepted with a changed algorithm, an unverified signature, a missing expiry or a key that never rotates.

Medium

Old API versions left running

A v1 endpoint without the access checks added in v2 is still reachable.

Medium

No limits on expensive operations

Login, OTP and search endpoints that allow unlimited attempts or very large queries.

Medium

Unsigned or replayable webhooks

Receivers that trust any request, or accept the same signed payload more than once.

Severity shown is typical, not fixed. We rate each finding on its real impact in your environment.

Approach

How we test it

  1. Build the API map

    We combine your documentation, collections and live traffic to list every endpoint, method, parameter and role, including the ones nobody documented.

  2. Test authorization exhaustively

    For each object and function, we try every role and tenant combination to find where access checks are missing or inconsistent.

  3. Attack tokens and sessions

    We examine how tokens are issued, validated, scoped, refreshed and revoked, and where trust can be forged or extended.

  4. Abuse inputs and logic

    We work through injection, mass assignment, data exposure and rate limits, guided by the OWASP API Security Top 10, and look for workflow abuse specific to your product.

  5. Prove and prioritise

    Every finding comes with a reproducible request, a clear impact statement and a fix your developers can apply directly.

Read our full methodology

Deliverables

What you receive

Every finding comes with proof-of-concept evidence, so your engineers can reproduce it and your auditors can trust it.

Executive summary

A plain-English view of risk for leadership, boards and customers.

Technical findings

Each issue with impact, evidence, reproduction steps and a clear fix.

Free retest

Once you’ve fixed the findings, we retest them and update the report.

Attestation letter

A letter you can share with customers and auditors to show testing was done.

Preparation

What we need from you

We'll confirm the details during scoping. Having these ready helps testing start on time.

  • API documentation, an OpenAPI/Swagger file or a Postman collection
  • Credentials or API keys for each role, ideally in two separate tenants
  • The base URL of the environment to test
  • Any client apps that use the API (web, mobile), if they are in scope
  • A technical contact for questions during testing
  • An agreed testing window and any rate or data limits

FAQ

API testing questions

Can you test an API without documentation?

Yes. We can map the API from the client apps that use it and from live traffic. Documentation speeds things up and improves coverage, so share whatever you have.

Do you test GraphQL?

Yes. GraphQL brings its own risks, such as introspection, deeply nested queries, batching and field-level authorization, and we test for all of them alongside the standard API checks.

Is an API test different from a web application test?

A web app test covers the API your front end calls. A dedicated API test goes further, covering every endpoint and version, including ones no client uses, and is the right choice for public, partner or mobile-only APIs.

Will testing affect our rate limits or data?

We agree limits and test data up front, and we test in a way that stays within them. A production-like staging environment is preferred for anything that creates or changes data.

Is a retest included?

Yes. Once you have fixed the reported issues, we retest them at no extra cost and update the report with their status.

Need a pentest for an audit, a customer, or peace of mind?

Tell us what you need tested. You’ll get a fixed-fee proposal with tester-days and timeline stated, usually within a few days of the scoping call.