04 /Security Assessment
API Security Testing
Your API gets tested at the endpoint rather than through the screen that normally calls it. That removes every constraint the front end was quietly supplying: the hidden field, the disabled button, the identifier you were never shown. What is left is whatever the server checks for itself, which is routinely less than the team believes.
What you get
An endpoint inventory, including the forgotten ones
Built from your specification, from traffic captured while using the product, and from routes that answer requests while appearing in no document. Deprecated versions left quietly running are a recurring find.
An authorisation matrix tested cell by cell
Every role is pointed at every sensitive operation and the result recorded. Broken object-level authorisation never announces itself; you see it only when one account successfully reads another account’s record.
Input handling probed at the boundary
Injection, type confusion, oversized payloads, extra fields accepted into a model, and parameters the client never sends. Validation living only in the browser is validation that does not exist.
Abuse and rate-limit behaviour
What an endpoint does when it is called a thousand times, when a one-time token is replayed, or when a workflow is entered halfway through. Scanners label these informational; an attacker treats them as the way in.
Findings that arrive as runnable requests
Each issue comes with a request your developer can send, not a paragraph describing one. That removes the argument about whether the finding is real and shortens the fix to an afternoon.
How it runs
- 01
Collect the surface
We take whatever specification exists, proxy real traffic while working through the product, then compare the two. The gap between the documented API and the answering API is usually where the interesting work begins.
You provide: A base URL, any API documentation you hold, and accounts for each role
We produce: An endpoint inventory annotated with roles and expected access
- 02
Write down the intended rules
For each endpoint we agree who ought to be able to call it and what they ought to see. A test for broken access control means nothing without a stated version of correct access control to test against.
We produce: An agreed authorisation matrix
- 03
Test the endpoints
Manual probing across authentication, authorisation, input handling and business flow, with tooling taking the repetitive sweeps. Every candidate is confirmed a second time before it is written down, because a finding withdrawn later costs more credibility than one found late.
We produce: Confirmed findings · Reproduction requests
- 04
Report and verify
Issues are written up with impact stated in terms of your data rather than in category names, then verified once the corrections ship.
We produce: API assessment report · Verification of the corrected endpoints
Where this stops
- Not a certified penetration test. No accreditation body stands behind this work and we carry no notified-body status, so a contract or an insurer specifically naming a formal pentest needs a supplier who holds that paperwork.
- Not load or performance testing. We look at how an endpoint behaves when it is abused rather than how it holds up under legitimate concurrency, which is a separate exercise needing its own rig and instrumentation.
- Not a review of the infrastructure underneath. Gateway policy, cloud identity configuration and network segmentation stay with your platform team.
- Not a source code review. The work runs against the running service; where you share a repository we will read it to confirm a finding, but a line-by-line pass over the codebase is different work with a different price.
Related reading
- Application security
OWASP assessment vs penetration test: which one your requirement names
Suppliers use the two terms interchangeably. Contracts, insurers and regulators do not. How to read the clause you have been given before you buy the wrong thing.
- Application security
Broken object level authorisation: the API risk no scanner will find for you
The top entry on the OWASP API Security Top 10 returns a perfectly normal 200 to the wrong person. Why tooling cannot see it, and how the testing actually runs.
- Application security
Triaging dependency vulnerabilities: what to do with 400 open alerts
A scanner dashboard nobody opens is worse than no scanner. How to sort advisories by whether they can actually be triggered, and how to record the ones you defer.
FAQ
API Security Testing questions we hear often
We already scan our API. How is this different?
The difference is the category that matters most. A scanner sends known-bad input at documented endpoints and reports whatever echoes back. It has no concept of which account should be permitted to read which record, so broken object-level authorisation passes through it untouched. Catching that needs two accounts, a written expectation of who may do what, and somebody patient enough to try the combinations.
Do you need our OpenAPI specification?
It helps, and it is not required. A specification speeds up the inventory and states what the API is supposed to do, which makes disagreements between intent and behaviour easy to spot. Without one we build the surface by proxying the application and probing for routes that respond. Teams are frequently surprised by what turns up that way, and the surprise is itself a finding.
Can you test a GraphQL API?
Yes. The mechanics shift more than the principles do: introspection exposure, query depth and cost, batching abuse and resolver-level authorisation replace the endpoint-by-endpoint sweep. The recurring problem is the one REST has as well, which is that a field is protected in the resolver everybody remembers and left open in the one nobody does.
Will this break anything?
Testing writes data. Records get created, states get changed, and something will end up in a strange condition, which is why a staging environment is preferable and why the window is agreed beforehand. Against production we stay inside the limits you set and tell you immediately when something looks wrong rather than holding it for the write-up.
Contact
Have a project in mind?
Tell us what you are building — or what keeps breaking. You will get a considered reply from an engineer, not an autoresponder.