01 · API and Web Security Testing
The flaws scanners don't find
Automated scanners test for known patterns. Injection signatures, missing headers, exposed credentials. Useful for baseline hygiene but useless for business logic. Can a user reach another user's data by changing an ID? Can a payment be submitted twice under concurrent requests? Can a privilege be escalated by replaying a modified JWT? These are logic questions, not signature questions. No tool can answer them without understanding what the system is supposed to do. Context is all.
# BOLA: accessing another user's account data GET /api/v2/accounts/1045 Authorization: Bearer eyJhbG...user_1044 200 OK { "account_id": 1045, "balance": "£142,800.00" } # Same request after remediation 403 Forbidden { "error": "insufficient_permissions" } # No scanner tests for this. It requires understanding # that the token and the resource should match.
We test against the OWASP Web and API Security Top 10s as a starting framework, applying those to the specific logic and features of your system. BOLA, broken authentication, mass assignment, SSRF, race conditions in payment and state-change flows, chained privilege escalation, JWT implementation flaws, GraphQL abuse.
Burp Suite Pro plus manual testing against real attack scenarios. Where useful, K6 load testing in the same engagement. A rate limit that can be bypassed is both a performance risk and a vulnerability.
You get: a report with full reproduction steps, business impact, and a prioritised fix for every finding. What to change, in what order, and why, walked through with your engineers.
Typical engagement: two to four weeks.