Key points
- Every object reference is tested with a second account — broken object level authorisation remains the most common critical finding.
- GraphQL gets specific treatment: introspection, query depth and cost, batching abuse and field-level authorisation.
- Tested independently of any client, because that is how an attacker reaches it.
- Includes an OpenAPI/collection review so undocumented endpoints get found too.
Your API does not know that the mobile app hides the delete button. If authorisation is enforced in the interface rather than on the endpoint, the API is one curl command away from a data breach — and the request will look completely legitimate in your logs.
What the engagement covers
Authorisation testing on every object
BOLA and BFLA testing across all roles and tenants, using paired accounts so cross-account access is proven rather than assumed.
Authentication and token security
JWT algorithm confusion and signature handling, token expiry and revocation, refresh-token rotation, API key scoping, and OAuth flow misuse.
Data exposure
Endpoints returning more than the client renders, verbose errors, internal identifiers, PII in logs and analytics, and debug fields left in serialisers.
Input handling and mass assignment
Injection across parameter types, mass assignment of privileged fields such as role or balance, and inconsistent validation between endpoints handling the same object.
Resource consumption
Rate limiting, pagination limits, expensive query patterns, file upload sizes, and GraphQL query depth and complexity controls.
Inventory and surface
Shadow and zombie endpoints, deprecated versions still routable, staging APIs reachable from the internet, and documentation that does not match reality.
How it runs
-
01
Specification review
OpenAPI spec, Postman collection or captured traffic becomes the map; gaps between documented and live endpoints are flagged immediately.
-
02
Role matrix
A test matrix of every role against every endpoint and object — the artefact that makes authorisation testing complete rather than anecdotal.
-
03
Manual exploitation
Authorisation, authentication, injection and logic testing driven by hand, with tooling used for coverage rather than judgement.
-
04
Chaining
Findings combined into realistic attack paths — an ID leak plus a missing check is a full data export.
-
05
Report and fix session
Findings with raw requests and responses, plus a session with the backend team on the fix pattern.
-
06
Free retest
Verification of every fix and a reissued report within 30 days.
What you receive
- Endpoint-by-role authorisation matrix with pass/fail status
- Findings with raw HTTP requests, responses and reproduction commands
- Fix patterns for your framework, not generic advice
- OWASP API Security Top 10 coverage mapping
- Remediation walkthrough call
- Retest report and attestation letter
Who this is for
- Mobile backends
- B2B SaaS APIs
- Fintech and payment integrations
- Products exposing partner or public APIs
Questions about this engagement
We have no API documentation. Is that a problem?
No. Endpoints are recovered from client traffic, the mobile bundle and directory enumeration. Undocumented endpoints are usually where the interesting findings live.
Do you test GraphQL differently?
Yes. Introspection exposure, query depth and cost limits, batching and aliasing abuse, and field-level authorisation are all specific to GraphQL and are tested separately from REST controls.
Can this run alongside our mobile app test?
It usually should. Bundling the app and its backend into one engagement removes the seam where each side assumes the other enforces authorisation.
How do you avoid hammering our environment?
Request rates are agreed up front, destructive verbs are opt-in, and testing pauses on request. You get a contact channel that is monitored for the whole window.