APIs are where the data actually is, and they are tested far less often than the screens in front of them. Protonyte tests REST, GraphQL and SOAP interfaces against the OWASP API Security Top 10 for teams in the United States, the UK, Canada and the Gulf - object-level authorisation first, because that is what keeps turning up, and the forgotten version-one endpoint nobody remembered was still answering.
A web page hides what it does not want you to see. An API hands you the whole request and waits. There is no interface to constrain you, no dropdown limiting the value, no page flow enforcing an order - only whatever the server chooses to check.
That is why the OWASP API Security Top 10 is led by authorisation rather than injection. The question is almost never "can I make this crash"; it is "can I ask for somebody else’s record and be given it". We test that with two real accounts and a long, patient list of every object your API knows about.
The ten categories of the OWASP API Security Top 10, applied to the endpoints your service actually exposes.
Asking for a record that belongs to somebody else, and getting it.
How the API decides a request is genuine.
Reaching an action, or a field, that is not yours.
Everything the server parses on your behalf.
Making your API fetch something on the attacker’s behalf.
The endpoints and versions nobody is watching any more.
We agree which services are in scope and ask for two accounts at each permission level, which is what authorisation testing needs.
Documentation describes the API somebody meant to ship. We find the one that is answering.
Every object, every account, both directions, before anything else is attempted.
Injection, resource abuse, SSRF and configuration, against the inventory rather than the documentation.
Findings by OWASP API category, with the exact call that proves each one, then a free retest.
Two documents and a conversation. Written so the person who signs the invoice and the person who writes the fix can both use them.
The work follows OWASP API Security Top 10, OWASP Web Security Testing Guide, OWASP ASVS and NIST SP 800-115, so the coverage can be checked rather than taken on trust, and the report maps to what your auditor or your enterprise customer already recognises.
This page is one part of our penetration testing service. Where a finding needs a different kind of engagement to answer properly, we say so in the report rather than selling you the test we happen to be running.
Base URLs, two accounts at each permission level, and written authorisation. A Postman collection, an OpenAPI or GraphQL schema speeds things up considerably, but we can work without one by watching the real clients and discovering the rest.
Because the most common serious API finding is broken object-level authorisation, and you cannot demonstrate it with a single login. With two accounts we can ask for one customer’s records as the other and show you the response, which is very hard to argue with.
The categories are the same but the attacks are not. GraphQL adds introspection, deeply nested and recursive queries, aliasing and batching, and authorisation that has to hold at every resolver rather than once at the endpoint. We test all of it.
Yes, and we would recommend it. We capture the real traffic from the app, build the inventory from that, and then test the API directly - which is exactly what an attacker does once they have your app on a phone they control.
No. Resource-exhaustion testing is done carefully and by agreement, usually against a non-production environment, and we stop at the point where the issue is proved rather than the point where something falls over.
Tell us what you need tested. Our team will reply with a clear scope and quote.
An assistant, not a person, so check anything important with us. Please do not type passwords or card numbers here. Messages are kept so we can answer you better.