Your API is the real application. The web front end and the mobile app are two clients of it, and an attacker does not use either — they talk to the API directly, without the constraints your interface imposes.
That gap is where API assessments earn their keep. A field the UI marks read-only is often writable. An endpoint the UI never calls is often still live. A parameter the UI always sends as the current user’s ID will happily accept somebody else’s.
Who this is for
- You run a SaaS platform where customers, partners or integrators call your API directly.
- Your mobile app or SPA is backed by an API that has never been tested as a system in its own right.
- You expose a public or partner API and need to know what it permits beyond the documented surface.
- You have a microservice estate where internal services trust each other more than they should.
What we actually test
Broken object-level authorization (BOLA / IDOR)
The single most common serious API finding, and the reason APIs need dedicated testing. Every object identifier, in every endpoint, exercised against every role: can I read, edit or delete an object that belongs to someone else simply by changing a number, a UUID or a tenant key? We test this systematically rather than by sampling: a role-versus-object matrix, worked through, not spot-checked.
Broken function-level authorization (BFLA)
Administrative and privileged endpoints reachable by ordinary users. Undocumented endpoints discoverable from JavaScript bundles, mobile binaries, API specifications or predictable naming. HTTP method confusion, where GET is protected but PUT is not.
Authentication, tokens and sessions
Token issuance, expiry and revocation; JWT algorithm confusion and alg: none acceptance; claims trusted from the client; weak signing keys; OAuth and SAML flow weaknesses; API key handling and leakage; refresh-token abuse. Tokens that carry authorization decisions instead of identity are a recurring, high-impact finding.
Business logic and mass assignment
Can an object be created or updated with fields the UI never exposes — role, isAdmin, balance, tenantId? Can workflow steps be invoked out of order, or skipped entirely? Can a rate limit, quota or approval step be bypassed by calling the API directly?
GraphQL specifics
Introspection exposure, query depth and complexity abuse, batching attacks, field-level authorization gaps, and resolvers that enforce access control inconsistently across different query paths to the same data.
The rest
Injection through API parameters, server-side request forgery from webhook and integration features, excessive data exposure (returning whole objects and filtering in the client), improper error handling that leaks internals, insecure direct file access, and transport and CORS configuration.
How we work with your API
- Surface discovery. Documentation and specifications where they exist — but we also derive endpoints from the clients, because the documented surface and the real surface are rarely the same thing.
- Role matrix. We build a map of every role against every endpoint and object, then work through it. This is what makes authorization coverage systematic rather than anecdotal.
- Manual exploitation. Confirming genuine impact, and chaining findings — individually minor issues that combine into full account or tenant takeover (a worked example).
- Report and retest, as with every engagement.
Common questions
Can you test an API without a user interface?
Yes – that is the normal case. We work from a specification, a collection, traffic captures, or the client application itself. An API with no UI at all is entirely testable.
Do you need an OpenAPI or Swagger specification?
It helps and speeds things up, but it is not required, and we do not rely on it alone: specifications are frequently incomplete, and undocumented endpoints are often the interesting ones.
How is this different from testing the web application?
A web application test exercises the API through the interface, which constrains what gets sent. An API test removes that constraint and tests every endpoint against every role directly – including endpoints the interface never calls.
Do you test GraphQL as well as REST?
Yes, and GraphQL needs specific attention: introspection, query depth and batching abuse, and field-level authorization that is enforced on one query path but not another.
What about rate limiting and denial of service?
We assess whether rate limits and quotas can be bypassed, which is a real authorization and business-logic issue. Load and denial-of-service testing that could affect availability happens only with explicit written agreement.
Talk to us about testing your API
Expert-led testing of complex authenticated applications – multi-tenant isolation, authorization/BOLA, business-logic and workflow abuse, complex role models – with developer-usable remediation.
Tell us what the application does and what worries you about it. We will come back with scoping questions, a clear proposal and a realistic timeline — and if a test is not what you need yet, we will say so. Get in touch.
See also: web application testing · mobile application testing · what SSRF is and why it matters.