Web Application Security

OWASP-aligned, manually-driven, business-logic aware.


Web app testing is where a lot of my time has gone over the years. The OWASP Top 10 is a perfectly reasonable starting point, but in practice the bugs that hurt people are rarely textbook injection or stored XSS — they're business logic flaws, broken access controls, and authentication edge cases that automated scanners can't reason about because they don't understand what the application is supposed to do.

I test web applications and APIs against both authenticated and unauthenticated threat models. That means horizontal and vertical privilege escalation, IDOR, race conditions, JWT and OAuth flows that don't quite hold up under scrutiny, and the kind of multi-step attacks that only show up when you've spent enough time clicking around to understand the workflow. SSRF, insecure deserialization, prototype pollution, server-side template injection — the usual suspects all get a turn, but they sit alongside the logic work, not in place of it.

For modern stacks I cover single-page applications, REST and GraphQL APIs, webhook integrations, and the supporting infrastructure: CDN configuration, CSP, CORS, and the response headers people forget about until something burns. Mobile back-end APIs slot naturally into the same engagement — the interesting bugs are usually server-side anyway.

Reports are written for two audiences. Developers need to fix the bug, so each finding includes a clean reproduction, the underlying cause, and remediation that's specific rather than “validate input.” Decision-makers need to understand the risk, so the executive summary actually summarises — without inflating severity to justify the engagement.


Discuss a web application or API assessment →

← Back to all services