API penetration testing
Your API is your business logic without the user interface in front of it. Every control the front end appears to enforce has to be enforced again server-side — and that is where we start looking.
4–8 days
Typical effort, scaling with endpoint count and role complexity.
REST · GraphQL · gRPC
All three surfaces, plus WebSocket and webhook flows.
Multi-role
Every permission tier tested against every object it should not reach.
Free retest
Fixes verified and the report reissued at no extra cost.
Mapped to the OWASP API Security Top 10
Broken object level authorisation alone accounts for a large share of real-world API breaches. It gets proportionate attention.
| Risk | What we test |
|---|---|
| API1 — Broken object level authorisation | Every endpoint accepting an object identifier, tested from every role, against objects belonging to other users and other tenants. |
| API2 — Broken authentication | Token issuance, validation, expiry and revocation. JWT signature and algorithm handling. Credential stuffing resistance. |
| API3 — Broken object property level authorisation | Mass assignment through unexpected fields, and responses returning more properties than the client should see. |
| API4 — Unrestricted resource consumption | Rate limiting, pagination bounds, query complexity limits and the cost of expensive operations. |
| API5 — Broken function level authorisation | Administrative and privileged endpoints reached by lower-privileged roles, including undocumented methods. |
| API6 — Unrestricted access to sensitive business flows | Automation resistance on flows with real cost: registration, redemption, purchase, invitation. |
| API7 — Server side request forgery | Any parameter accepting a URL, tested for internal network and cloud metadata access. |
| API8 — Security misconfiguration | CORS policy, verbose errors, debug endpoints, missing transport security, permissive HTTP methods. |
| API9 — Improper inventory management | Undocumented, deprecated and unversioned endpoints still reachable in production. |
| API10 — Unsafe consumption of third-party APIs | Trust placed in upstream responses, and what happens when an integration returns something unexpected. |
Surface-specific testing
GraphQL
- Introspection exposure and schema disclosure
- Query depth and complexity denial of service
- Batching abuse to bypass rate limits
- Field-level authorisation gaps between resolvers
- Mutation authorisation independent of query authorisation
gRPC
- Reflection service exposure in production
- Protobuf message manipulation and field injection
- Interceptor and metadata-based authorisation flaws
- Streaming endpoint resource consumption
Webhooks & async
- Signature verification on inbound webhooks
- Replay resistance and idempotency handling
- SSRF through outbound webhook destinations
- Queue and event authorisation boundaries
What we need from you
- An OpenAPI, GraphQL schema or Postman collection — or a proxy capture if none exists
- Two accounts per role, so cross-user authorisation can actually be tested
- Tenant separation details if the API is multi-tenant
- Written authorisation and confirmed environment scope
- Rate limit expectations — tell us what should be enforced so we can confirm it is
No documentation? That is common and not a blocker. We can map the surface from a proxy capture of the client application, and the undocumented endpoints we find in the process are frequently the interesting ones.
Find the authorisation gap before someone else does.
Claim one free verified finding against your API, or book a scoping call.