Core Capability
API & Microservices Penetration Testing
APIs are where the transactions happen, and where authorisation is most often assumed rather than enforced. We test REST, GraphQL and the service-to-service layer behind them.
- Aligned to the OWASP API Security Top 10
- Every object identifier tested for authorisation, not just authentication
- Includes discovery of undocumented and orphaned endpoints
Where API security actually fails
Authentication is usually solved: a request without a valid token gets rejected. Authorisation is where systems break, because it has to be enforced on every object, on every endpoint, every time. Miss it in one handler and a valid token becomes a key to everyone's data.
That is why our API testing is object-level rather than endpoint-level. We enumerate identifiers, then attempt to read, modify and delete each one from an account that should have no access to it.
What we test
Authorisation flaws
- Broken object-level authorisation (BOLA) across every enumerable identifier
- Broken function-level authorisation (BFLA) on administrative and privileged operations
- Mass assignment, where a request writes fields the interface never exposes
- Multi-tenant scoping, confirming the tenant is derived from the session rather than trusted from the request
Token and session handling
- JWT implementation: algorithm confusion, unverified signatures, missing expiry and audience checks
- Refresh token rotation, revocation on logout and behaviour after a password change
- API key scoping, rotation and exposure in client-side code or repositories
GraphQL specifics
- Introspection exposure and schema disclosure in production
- Query depth and complexity limits, and resource exhaustion through nested queries
- Batching abuse used to defeat rate limiting and brute-force protection
- Field-level authorisation, which resolvers frequently omit even when the query is authorised
Microservices and internal traffic
- Service-to-service authentication, including services that trust any caller inside the network
- Gateway bypass routes that reach a service directly without passing the edge policy
- Internal endpoints unintentionally exposed through ingress or misconfigured load balancers
- Message queue and event bus authorisation where downstream consumers trust the payload
Shadow API discovery
Most environments run endpoints nobody remembers deploying: a version 1 that was never retired, a debug route left enabled, an internal service that became reachable after an infrastructure change. These are attractive precisely because they are outside your monitoring and outside your review process.
We reconstruct your real external surface from traffic analysis, client bundles, mobile binaries, DNS and certificate data, then test what we find rather than only what the documentation lists.
What you receive
- A tested inventory of your true external API surface, including endpoints not in your documentation
- Proof of concept requests for every authorisation failure, ready to replay
- Patch guidance at the handler and middleware level, not just a list of affected routes
- Recommendations for gateway policy and service-to-service authorisation
- Compliance-ready evidence for your audit programme
How we run the authorisation matrix
Authorisation is where API engagements earn their value, so it is worth being specific about the method rather than only the intent.
We build a matrix of every endpoint against every role and every token type, then replay each captured request as each identity and compare responses. Object-level authorisation is tested by substituting identifiers belonging to other users and other tenants; function-level authorisation by calling administrative operations with ordinary credentials. Asynchronous paths are included, because background jobs and webhook handlers frequently execute with wider privileges than the request that triggered them.
The work scales with identity pairs rather than endpoint count, which is why an API serving eight roles across two tenants takes substantially longer than one serving three roles. That is also why the scope states which pairs were covered: skipping combinations is where an API assessment quietly loses its value, and it is invisible in a report that does not say.
- One account per role, including read-only, trial, suspended and support roles
- Two accounts in the same role, so access between peers can be tested
- Accounts in two separate tenants where the platform is multi-tenant
- Machine-to-machine credentials for each distinct service scope, since those are usually the most broadly permissioned
Common questions
Do you need our OpenAPI specification or documentation?
It helps and we will use it, but we do not rely on it. Documentation describes the API you think you have; we test the one you actually expose, which is why endpoint discovery is part of every engagement.
Can you test against a non-production environment?
Yes, and it is often preferable for destructive test cases. The requirement is that the environment matches production in routing, authorisation configuration and data model, otherwise the results will not transfer.
What about internal APIs that are not exposed to the internet?
They are worth testing, because most breaches involve an attacker who has already reached the internal network. We can test from an internal position to show what a compromised service or workstation could reach.
How is API testing different from web application testing?
There is no interface to constrain what you send, so every endpoint and parameter is directly reachable and assumptions the front end enforced are simply absent. The dominant findings shift towards object-level and function-level authorisation, excessive data in responses, and mass assignment — which is why the API-specific OWASP list exists separately.
Do you test GraphQL differently from REST?
Yes. GraphQL concentrates risk differently: introspection exposes the full schema, nested queries enable resource exhaustion, aliasing can defeat naive rate limiting, and authorisation has to be enforced at field and resolver level rather than per endpoint. A single mutation can also reach several backend services, which widens the impact of one authorisation gap.
Do you test rate limiting and resource consumption?
Yes, and per-account rather than only per-address, since rotating source addresses is trivial. We check whether limits protect expensive operations specifically — search, export, report generation, third-party calls — and whether pagination limits can be overridden to pull an entire dataset in a single request.
What about APIs authenticated with machine-to-machine tokens?
Those get particular attention, because service credentials are usually long-lived and broadly scoped. We test whether a token issued for one purpose is accepted for others, whether scope is enforced or merely recorded, whether tokens can be exchanged for wider access, and how revocation behaves. Over-scoped service tokens turn a small compromise into a large one.
Let's scope your infrastructure.
Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.