Broken object-level authorisation
Every endpoint that accepts an identifier is tested against objects belonging to other users and other tenants. This is the finding that ends careers.
Application Security
Your API is the product. Test it like one.
The user interface is a suggestion. The API is what actually enforces your rules — and it answers requests that no screen in your product would ever send.
OWASPAPI Top 10
RESTGraphQL · gRPC
BOLAMost common critical
SpecDriven coverage
Why APIs fail differently from applications
A web application has a shape. There are pages, they link to each other, and a user moves through them in roughly the order the designers intended. An API has no such shape. It is a set of endpoints that will each answer any request that reaches them, in any order, from any client, with any parameters — and the only thing standing between a well-formed request and your data is whether somebody remembered to check authorisation on that specific route.
That is why broken object-level authorisation sits at the top of the OWASP API Security Top 10 and why it is still, by a distance, the most common critical finding we report. The pattern is always the same: an endpoint validates that you are logged in, and then trusts the identifier you sent it. Change the number, get somebody else’s record. It is trivial to exploit, it is invisible to a scanner that has no idea which records belong to whom, and it is catastrophic when the records are invoices, prescriptions or KYC documents.
We test APIs against their specification where one exists, and reconstruct one where it does not. Every endpoint, every method, every parameter, every role — including the endpoints that are deployed but undocumented, which in our experience is most of the interesting ones.
Coverage
What we test
Coverage follows the OWASP API Security Top 10, extended for GraphQL and internal service-to-service traffic.
Broken function-level authorisation
Administrative and privileged routes probed with lower-privilege tokens, including methods the documentation does not list.
Authentication and token handling
JWT signature and algorithm handling, token expiry and revocation, refresh flows, API key scoping, and OAuth implementation errors.
Excessive data exposure
Responses returning more fields than the client displays — the classic case where the front-end hides what the server happily sends.
Resource consumption and rate limiting
Missing throttling, unbounded pagination and expensive queries that make a single request costly to serve.
GraphQL-specific classes
Introspection exposure, deeply nested and recursive queries, batching abuse, and field-level authorisation that is enforced inconsistently across resolvers.
Mass assignment and input validation
Object properties that can be set through the API but were never meant to be client-controlled — role, balance, verified, is_admin.
Business logic and workflow
Operations replayed, reordered or invoked out of sequence, and state transitions that the API permits but the product does not.
Approach
How an API test runs
Faster than a full application test when a specification exists, because coverage can be driven from it directly.
-
01 · Import or rebuild the specification
OpenAPI, Swagger, Postman collection or GraphQL schema. Where none exists we reconstruct the surface from traffic and client code.
-
02 · Map roles and objects
Which identities exist, what each one legitimately owns, and therefore what each one must never be able to reach.
-
03 · Automated coverage
Every documented endpoint and method exercised for known classes, misconfiguration and exposure, with dependency and version issues matched against current intelligence.
-
04 · Authorisation matrix testing
The methodical part, and the reason this service exists: every endpoint tested with every role against objects belonging to somebody else.
-
05 · Logic and abuse testing
Sequence, replay, quantity and state-transition abuse, plus consumption testing where availability is in scope.
-
06 · Report and retest
Findings mapped to endpoints and methods so the fix has an obvious owner, then a free retest.
Run against recognised standards
- OWASP API Security Top 10Primary coverage model
- OWASP ASVSVerification requirements for API controls
- CWEWeakness classification
- ISO 27001 Annex AControl mapping
Deliverables
What you actually receive.
The report is the product. If it cannot be acted on by a developer and understood by a director, we have not finished.
Findings mapped to endpoints
Every issue names the route, method and parameter, so the fix lands on one team’s backlog without a triage meeting.
Authorisation matrix
A grid of roles against endpoints showing exactly where the boundary held and where it did not.
Reproduction as raw requests
Copy-paste requests your engineers can replay immediately, not screenshots of a proxy tool.
Machine-readable export
SARIF and JSON for direct import into your pipeline or ticket queue.
Free retest
Verification once fixes ship, with per-finding state recorded.
Is this for you?
Talk to us if any of these are true.
If none of them are, say so on the call and we will tell you honestly whether this is the right piece of work — or point you at the one that is.
Book a scoping call- You sell an API, or your mobile app and web front-end share one.
- You are multi-tenant and tenant isolation is enforced in application code rather than at the data layer.
- You have moved to microservices and internal service-to-service calls are implicitly trusted.
- You expose a GraphQL endpoint and introspection has never been reviewed.
- Partners integrate with you directly, using long-lived API keys nobody has audited.
How we work
Six steps, and no surprises.
The same engagement model applies to every piece of work we take on, so you always know what happens next.
01
Scope
A 30-minute call, then a written scope: what is in, what is out, what we need from you and what it costs. Nothing starts before you sign it.
02
Authorise
Rules of engagement, testing windows, escalation contacts and a signed authorisation. Out-of-hours windows where production cannot take the load.
03
Test
Automated coverage first, then manual testing where judgement is required. Critical findings are reported the day we confirm them, not at the end.
04
Report
One report a developer can act on and an executive can read, with evidence, reproduction steps, business impact and a fix for every finding.
05
Remediate
A walkthrough call with your engineers. We answer questions on the fix, not just the finding.
06
Retest
A free retest cycle to confirm the fixes hold, and a clean summary you can hand to a customer, auditor or board.
Questions
API Security Testing — answered.
The questions clients actually ask during scoping. If yours is not here, ask it directly.
What is BOLA and why does it matter so much?
Broken Object-Level Authorisation is when an endpoint confirms that you are authenticated but does not confirm that the specific record you asked for belongs to you. Change an identifier in the request and you receive somebody else’s data. It is the most commonly exploited API flaw, it requires no special skill to abuse, and automated scanners cannot detect it because they have no concept of which records should belong to which user. Finding it requires testing with multiple real accounts, which is exactly how we do it.
Do you need our API documentation?
It helps a great deal and makes the engagement faster and cheaper. An OpenAPI or Swagger specification, a Postman collection or a GraphQL schema lets us drive coverage directly from the definition. Where documentation does not exist we reconstruct the surface from client applications and observed traffic — that is normal, and the undocumented endpoints we uncover in the process are often the most interesting part of the report.
Can you test GraphQL?
Yes, and it needs its own treatment. GraphQL moves authorisation down to the resolver level, so a single schema can enforce field access consistently in one place and inconsistently in another. We test introspection exposure, query depth and complexity limits, batching abuse, and field-level authorisation resolver by resolver.
How do you test internal APIs that are not internet-facing?
From inside. We either work from a jump host you provide, a VPN connection, or a container we run within your environment. Internal service-to-service APIs are worth testing precisely because they are usually built on an assumption of implicit trust — once an attacker has any foothold, that assumption is doing all the security work.
Will testing corrupt our data?
Testing runs against a non-production dataset wherever one exists. Where production testing is agreed, write and destructive operations are constrained to accounts and records you nominate, and everything we create is recorded so it can be cleaned up afterwards. This is agreed in writing before any request is sent.
Next step
Get a written scope and a fixed price.
A 30-minute call, then a scope document with what is in, what is out and what it costs. No obligation, and no charge for the conversation.