Web Application Penetration Testing
We test web applications by hand, the way an attacker would — including the business logic that automated scanners cannot reach. Every engagement is led by a senior practitioner, not handed to a tool.
- Manual testing, senior-led
- Mapped to OWASP Top 10 and ASVS
- Retest included
What we test
Six areas, worked through manually on every engagement. Coverage maps to the OWASP Top 10 and OWASP ASVS, so you can see exactly what was tested and what was not.
Authentication and sessions
Login flows, multi-factor handling, password reset, token lifetime and session fixation — the places where access is granted and revoked.
Authorization and tenant isolation
Whether one user can reach another user’s data, and whether one tenant can reach another tenant’s. Tested role by role, not assumed from the design.
Input handling
Injection, cross-site scripting, unsafe deserialization and file upload handling — everywhere untrusted input crosses into your application.
Business logic
Workflow abuse, race conditions, and steps that can be skipped, replayed or reordered. This is the category scanners miss entirely.
Backing APIs
REST and GraphQL endpoints behind the interface, including the ones the front end never calls but an attacker can still reach.
Configuration
Security headers, TLS settings, verbose error output and exposed administrative interfaces — the quiet defaults that widen an attack.
How an engagement runs
Five stages, agreed before we start. You always know what is in scope, what is being tested, and when you will hear from us.
-
1
Scoping
We agree the targets in writing, including what is explicitly out of bounds. Nothing outside that document gets touched.
-
2
Reconnaissance
We map the real attack surface — hosts, endpoints, roles and integrations — which is usually larger than the one on the architecture diagram.
-
3
Manual testing
Hands-on testing supported by tooling, run against staging wherever possible so production users are never affected.
-
4
Reporting
Every finding comes with evidence, reproduction steps and the business impact — written so your developers and your board can both act on it.
-
5
Retest
Once your fixes are in, we test them again and reissue the report. Confirming the fix is part of the engagement, not an extra.
What you receive
- A technical report with full evidence and reproduction steps for every finding.
- An executive summary written for people who will not read the technical report.
- Findings rated by business impact, not by CVSS score alone, so remediation is prioritised against your actual risk.
- A walkthrough call with the tester who did the work — not an account manager relaying it.
- A retest and an updated report once the fixes are deployed.
Scope and timing
A single-application engagement typically runs one to two weeks. Larger or multi-tenant platforms are scoped individually.
Critical findings are not held back for the report — we tell you the same day we find them.
Tell us about your application
Describe the application and who uses it, and we will come back with a scope and a price. No obligation, and no sales sequence.
Talk to a specialist