Object-level auth
Change the ID, get the other tenant. Horizontal and vertical. UUID is not access control.
BOLAIDOR
Coverage
Two accounts or it did not happen
Function-level auth
Admin mutations reachable as a user. Hidden verbs. Verb tampering.
BFLAAdmin
Tokens & sessions
JWT alg confusion, long-lived refresh, missing audience, leaked in logs.
JWTOAuth
GraphQL & mass assignment
Introspection in prod, batching, nested queries, binding extra fields into privileged updates.
GraphQLMass assignment
UK procurement teams have learned to ignore ‘possible IDOR’. The report they keep is the one with two sessions, two responses, and a screenshot of the other organisation’s invoice.
Why it matters
Authorisation is the whole game
Broken object-level authorisation, every time
BOLA — an endpoint that checks you are authenticated but not whether this record is yours — remains the most common serious finding in API testing, and it is invisible to scanners because they have no concept of ownership. We test it the only way it can be tested: two authenticated identities, and every object identifier the first one was never meant to know.
GraphQL fails in its own particular ways
Introspection left enabled in production, deeply nested queries with no depth or complexity limit, aliases used to defeat rate limiting, authorisation enforced at the resolver for some fields and nowhere for others, and batching that turns one request into a thousand. A REST checklist will not find any of it.
The endpoints nobody documented
Deprecated versions still routable, internal endpoints exposed through the same gateway, debug routes that survived a release, and the /v1 that was supposed to be switched off eighteen months ago. We work from your specification and then go looking for what the specification does not mention.
Mass assignment and the shape of your objects
If your API binds a request body straight onto a model, somewhere there is a field — is_admin, account_tier, organisation_id — that a user can set and should not be able to. This is a one-line finding with a total-compromise impact, and it is worth the whole engagement on its own.
APIs fail on logic, not on payloads. That is why this is a manual engagement with two identities and a model of your data, rather than a scan of your endpoints.
How it runs
The engagement, step by step
Scope and authorisation
Base URLs, environments, versions in scope, rate limits we should respect, and written CMA 1990 authorisation. If a third party hosts part of the API, we confirm you are entitled to authorise testing of it.
Specification and reality
We start from your OpenAPI or GraphQL schema, then enumerate what is actually routable. The gap between the two is often the first finding.
Modelling ownership
Which objects belong to which identity, which roles exist, and what each is supposed to reach. This model is what makes authorisation testing provable rather than speculative.
Authorisation testing
Every endpoint, every method, against a second identity and an unauthenticated caller. Object level, function level, and tenant isolation where the platform is multi-tenant.
Protocol and input testing
Token handling, expiry and revocation, replay, mass assignment, injection where the backend allows it, file handling, rate limiting, and error messages that leak more than they should.
Report and re-test
Findings with the exact request and response that proves them, in a form your engineers can replay. Re-test of every confirmed issue after the fix, included in the fee.
Deliverables
What lands on your desk
Replayable proof
Every finding ships with the raw request that demonstrates it — a curl command or a saved collection — so a developer can reproduce it in a minute rather than reconstructing it from prose.
Coverage statement
Which endpoints were tested, which were not, and why. An honest coverage note is worth more to an auditor than a report that implies everything was examined.
OWASP API Top 10 mapping
Mapped to the OWASP API Security Top 10, with ISO 27001 and UK GDPR relevance called out where an endpoint exposes personal data.
Re-test and attestation
Re-test of confirmed findings once patched, included, plus a letter of attestation naming the API version, scope, dates and outcome.
Scoping
What we need from you to start
- An OpenAPI or GraphQL schema if one exists — and the honest answer if it is out of date.
- Two accounts per role, in the same tenant and, for multi-tenant platforms, in different tenants.
- The base URL of the environment we are authorised to test, and confirmation of which versions are live.
- How authentication works: session, JWT, OAuth flow, API keys, and how tokens are issued and revoked.
- Rate limits and any WAF in front, so we can agree whether to test through it.
- A named contact for the two or three questions that always come up on day one.
No schema and no documentation is workable — we enumerate from the client applications instead — but it costs a day and slightly reduces coverage confidence. We would rather say that up front than discover it at the report stage.
UK compliance
Where this sits in a UK compliance programme
UK GDPR, Article 32
An API that lets one customer read another’s records is the textbook Article 32 failure and a reportable personal data breach if exploited. Independent testing with a re-test cycle is direct evidence of the required testing process.
ISO/IEC 27001
Evidences application security requirements and technical vulnerability management across the API estate, including the versions your architecture diagram forgot.
PCI DSS v4
Where an API touches cardholder data, Requirement 11.4 applies to it as much as to the web front end. We will scope honestly and tell you when your API is out of scope rather than bill for it.
Customer due diligence
Enterprise buyers now ask specifically about BOLA and tenant isolation. A report that names the identities used and shows the isolation test passing answers that question in one page.
Questions
What UK buyers ask before signing
Broken Object Level Authorisation is an endpoint that verifies you are logged in but not that the record you asked for is yours. Change an identifier, read somebody else’s data. It is the most common serious API finding, it is trivially exploitable at scale, and no automated scanner reliably finds it because it has no idea who owns what.
Yes. GraphQL gets its own treatment: introspection exposure, query depth and complexity limits, alias-based rate-limit evasion, per-resolver authorisation, and batching abuse. A REST methodology applied to GraphQL misses most of what matters.
It helps and it shortens the engagement, but it is not required. Without one we enumerate the surface from your client applications and traffic. We will tell you what that does to coverage confidence before you sign.
Four to seven working days for a typical product API, driven by the number of endpoints, roles and tenants rather than raw request volume. Reporting adds two to three days.
Some test data is unavoidable when testing write operations. We tag what we create so it can be found and removed, keep it to the minimum needed for proof, and hand you a list at the end. If that is a problem in your environment, tell us at scoping and we will constrain the testing instead.
Related
Engagements that usually run alongside
01
02
03
Web application VAPT
Authorisation, session, injection and business logic in the applications your UK customers log into.
02
Mobile app VAPT
Android and iOS clients, and the API behind them where the real risk usually sits.
03
Cloud security VAPT
IAM, storage, network boundaries and the CI/CD path into your AWS, Azure or GCP estate.
Ready to scope a UK engagement?
A thirty-minute call. Assets, timeline, a quote in pounds sterling.
Request a quote