Web application penetration testing.
Your web application is your largest attack surface and the one your customers touch. We test it the way an attacker would: authenticated, unauthenticated, and everywhere your framework defaults do not reach.
At a glance
- Typical duration
- 1 to 2 weeks plus reporting
- Approach
- Grey-box by default, black or white-box on request
- Standards
- OWASP Top 10, OWASP WSTG
- Retest
- Included
- Best paired with
- API testing and secure code review
What we look for.
Most web application breaches are not exotic. They are an access-control check that was never written, a password reset flow that trusts a parameter, or a file upload that trusts a filename. Scanners do not find these because they require understanding what the application is for. We test the logic, not just the surface.
What we test.
What you receive.
Risk posture in plain language for leadership and the board, with the two or three things that actually matter.
Severity, proof-of-concept evidence, reproduction steps and specific remediation, written for the engineer who has to fix it.
Findings mapped to SOC 2, ISO 27001, PCI DSS and HIPAA controls so your auditor can use the report directly.
A shareable letter confirming scope, dates and outcome, reissued free after we verify your fixes.
Who needs this.
- SaaS products entering enterprise procurement or security review
- Applications handling payments, health data or personally identifiable information
- Anything in scope for SOC 2, ISO 27001, PCI DSS or HIPAA
- Post-incident validation that a fix actually closed the hole
- Pre-launch products where a public breach would be existential
Frequently asked.
Do you need credentials?
Yes, and ideally one account per role. Most serious findings live behind authentication, and unauthenticated testing alone tends to produce a thin report. If provisioning accounts is difficult, tell us at scoping and we will plan around it.
Can you test against staging instead of production?
Yes, provided staging is a faithful mirror. Where staging diverges in authentication, data volume or third-party integrations, we will flag what could not be validated rather than imply coverage we did not have.
What about single-page applications?
A SPA is a client. The real attack surface is the API behind it, which is why we usually recommend pairing this engagement with API testing. We test the client for token handling, storage and logic exposed in the bundle.
How many findings should we expect?
We do not pad reports to look thorough. A mature application might produce three findings that matter and a handful of informational notes. A first-time test on a fast-shipping product usually produces more.
Related services.
Your mobile app and your single-page front end are just API clients. The API is the real target, and it is usually tested least. We test REST, GraphQL and the authorisation logic underneath both.
SVC 06Secure Code ReviewA penetration test finds what is exploitable from outside. A code review finds what is latent inside, including the flaw that is currently unreachable and will become reachable in the next release.
CMP 01SOC 2The certification your enterprise customers ask for by name, and the one most likely to be blocking a deal right now. We take you from gap assessment to a clean Type I or Type II report.
Ready to find out what an attacker would find?
Tell us about your environment and we will come back with a scoped quote and a start date. No discovery-call marathon, no obligation.