Service 1.2
API penetration testing.
We test your API directly, not only through your app: every endpoint, with the keys of each role, checking what each caller can read and change.
1 What we test
- Authorization on every object: whether a caller can read or change another account’s records by changing an ID.
- Authorization on every function: whether an ordinary caller can reach endpoints meant for admins or other roles.
- Authentication and tokens: how keys and tokens are issued, checked, refreshed and revoked.
- Mass assignment: fields a caller can set that they should not, such as a role, a price or an owner.
- Rate limits: whether one caller can hammer sign-in, costly searches or paid features. Checked with small bursts, never load testing.
- Input handling across REST and GraphQL, including GraphQL schema exposure and deeply nested queries.
Method: OWASP API Top 10, OWASP WSTG, NIST SP 800-115.
2 Not included
Load testing, third-party APIs you call but do not run.
3 What you provide
- An OpenAPI file or Postman collection, or the documentation your own developers use.
- Keys or accounts for each role, and two for any role whose users must not see each other’s data.
- The environment to test, production or staging, and its base URL.
- A contact we can call during the test windows.
- If a gateway or rate limit could block us, an allow list for our fixed IP addresses. We send them before the test.
4 How the test runs
- Scope call: we agree the endpoints, the roles, the test windows and who to call. You get a written offer with dates and price.
- You sign the authorization. Nothing reaches your API before that.
- We map every endpoint, from your documentation and from the traffic of your own app.
- Each endpoint is tested with each role, then with no key at all.
- A critical finding goes to your contact as soon as it is proven. It does not wait for the report.
- Report and readout, then a retest once you have fixed.
5 What you get
| Document | What it holds | For |
|---|---|---|
| Technical report | Each finding with its exploit path, proof, CVSS 4.0 score, CWE and fix. | Developers, IT |
| Executive report | Five to eight pages on business risk, in plain words. | Management, board |
| Remediation plan | Findings ranked by what to fix first. | IT, project leads |
| Readout | A remote session to walk through the findings and answer questions. | Both |
| Retest attestation | Proof that the findings were fixed. | Auditors, clients |
6 Questions
- How long does it take?
- It depends on the number of endpoints and roles. The written offer gives the number of testing days and the dates before you sign.
- We have no documentation. Can you still test?
- Yes. We map the API from your app’s traffic instead. It takes longer, and the offer counts that time.
- Do you test the APIs we call from other companies?
- No. Only APIs you run. Testing someone else’s API needs its owner’s consent.
- Is this the same as the web application test?
- It overlaps. The web test reaches the API through your screens; the API test calls every endpoint directly, including ones no screen uses.
Get a scope for this test
Tell us what needs testing. A tester replies with a written offer: scope, dates and price.
Request a scope