API penetration testing.
Your mobile app and your single-page front end are just API clients. The API is the real target, and it is usually tested least. We test REST, GraphQL and the authorisation logic underneath both.
At a glance
- Typical duration
- 1 to 2 weeks plus reporting
- Approach
- Authenticated, multi-role, specification-led
- Standards
- OWASP API Security Top 10
- Formats
- REST, GraphQL, gRPC on request
- Retest
- Included
What we look for.
Object-level authorisation is the most common serious API flaw and the hardest to find automatically, because a scanner cannot know that order 1041 belongs to a different customer than order 1042. We test with multiple accounts across multiple roles specifically to prove where that boundary fails.
What we test.
What you receive.
Risk posture in plain language for leadership and the board, with the two or three things that actually matter.
Severity, proof-of-concept evidence, reproduction steps and specific remediation, written for the engineer who has to fix it.
Findings mapped to SOC 2, ISO 27001, PCI DSS and HIPAA controls so your auditor can use the report directly.
A shareable letter confirming scope, dates and outcome, reissued free after we verify your fixes.
Who needs this.
- Platforms where partners or customers integrate directly against your API
- Mobile-first products where the API carries all business logic
- Anyone who has added endpoints faster than they have documented them
- Fintech, healthcare and marketplace products with multi-tenant data
- Teams preparing for a customer security review or SOC 2
Frequently asked.
Do you need our API specification?
It helps and it speeds things up, but we do not rely on it. We proxy real client traffic and enumerate independently, because the endpoints missing from your specification are frequently the interesting ones.
Can you test a GraphQL API?
Yes. GraphQL shifts the risk rather than removing it: introspection, query depth and complexity, batching and per-field authorisation all get tested explicitly.
How many roles should we provide?
At minimum two accounts at the same privilege level plus one of each elevated role. Two same-level accounts are what let us prove cross-tenant access rather than describe it as theoretical.
Is this included in a web application test?
Some overlap is unavoidable, but a dedicated API engagement goes considerably deeper on authorisation and enumeration. If budget forces a choice and your logic lives in the API, test the API.
Related services.
Your web application is your largest attack surface and the one your customers touch. We test it the way an attacker would: authenticated, unauthenticated, and everywhere your framework defaults do not reach.
SVC 04MobileApp store approval is a policy review, not a security review. We test iOS and Android builds statically and at runtime, and we test the API behind them, because that is where the data actually lives.
SVC 05CloudYour provider secures the cloud. You are responsible for what is in it. We test identity, exposure and blast radius across AWS, Azure and GCP, and we do it against your actual configuration rather than a checklist.
Ready to find out what an attacker would find?
Tell us about your environment and we will come back with a scoped quote and a start date. No discovery-call marathon, no obligation.