01 · API and Web Security Testing
Who can reach what they shouldn't?
Most security findings cost a bad week. A handful cost the business. What decides which is rarely the flaw's name. It's what it reaches. A broken permission check on the right endpoint is every customer record you hold. A payment flow that can be replayed is money moving before anyone notices.
This is not testing that only turns up disasters. Most findings are minor, fixed in an afternoon. The value is in the ones that aren't, caught while they're still a finding and not yet a headline.
# 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" } # This requires understanding that the token and # the resource should match. It's a logic check, not a signature.
The OWASP Web and API Security Top 10s are where we start, not where we stop. BOLA, broken authentication, mass assignment, SSRF, race conditions in payment and state-change flows, chained privilege escalation, JWT implementation flaws, GraphQL abuse. Those are the categories. What matters is whether any of them apply to what your system actually does, not whether they're on a list.
Manual testing against real attack scenarios, backed by the same tools any serious security team would use. Load and performance testing sits alongside it where the two meet: a rate limit that can be bypassed is both a performance problem and a vulnerability.
You get: reproduction steps, business impact, and a fix, in priority order, for every finding. Walked through with your engineers, not left in a PDF.
Typical initial engagement: two to four weeks.