An API exposes the business logic directly, without the interface that used to hide it. Identifiers are in the open, fields that the client never shows are still accepted by the server, and every endpoint is one request away from anyone with a token.
We work from the specification where there is one and rebuild it from traffic where there is not. Every endpoint is called as every role, with the identifiers of other users and tenants, with fields it should not accept and in an order the workflow does not expect.
01Scope
What we test
Object level authorisation: access to records of other users and tenants
Function level authorisation: administrative and internal operations
Property level authorisation: mass assignment and excessive data exposure
Authentication: API keys, OAuth 2.0 flows, JWT validation, token lifecycle
GraphQL: introspection, depth and complexity, batching, field authorisation
gRPC and WebSocket: method authorisation, message validation, channel hijacking
Server-side request forgery and unsafe consumption of third-party APIs
Inventory: shadow, deprecated and debug endpoints, version drift
02Approach
How the work is done
01
Inventory
We compare the specification with real traffic and with the mobile and web clients, and list the endpoints that exist but are not documented.
02
Authorisation matrix
Each operation is called with the credentials of each role against objects of other users and tenants. The result is a matrix of what is allowed against what should be.
03
Input and schema abuse
We send fields, types and structures the schema does not expect: extra properties, nested queries, oversized batches, conflicting content types.
04
Business flow abuse
Operations are replayed, reordered and run in parallel to find race conditions and flows that can be automated to the detriment of the business.
We have no documentation for the API. Can it be tested?
Yes. We rebuild the interface from the traffic of your clients and from the behaviour of the server. The missing documentation is itself a finding, and the inventory we build is part of the report.
How is this different from a web application test?
The target is the interface between systems, not the pages a person sees. The work concentrates on authorisation of every object and operation, on schemas and on automated abuse, which is where API breaches come from.
Do you test internal APIs between microservices?
Yes, from the network position you define: from the internet, from a partner network or from inside the cluster. Internal APIs often trust their callers more than they should.