Web application penetration testing
Your application is the part of your business that strangers are allowed to interact with. We test it the way someone who wants your data would — by hand, across every role, until we find the path that actually works.
5–10 days
Typical tester effort for a single application of moderate complexity.
All roles
Tested authenticated as every user type, plus unauthenticated.
2 reports
Technical detail for engineers, executive summary for the board.
Free retest
Fixes verified and the report reissued at no extra cost.
What we test for
Structured against the OWASP Web Security Testing Guide and verified to OWASP ASVS levels appropriate to your risk profile.
Access control
- Horizontal escalation — reaching another user's data at the same privilege level
- Vertical escalation — reaching administrative function as a standard user
- Insecure direct object references across every enumerable identifier
- Forced browsing to unlinked administrative and debug endpoints
- Multi-tenant isolation where one customer's data must never reach another
Authentication & session
- Credential handling — storage, transmission, reset and recovery flows
- MFA implementation and the bypasses that commonly defeat it
- Session lifecycle — fixation, invalidation, concurrency and timeout
- Token security — JWT algorithm confusion, signature validation, expiry
- OAuth and SSO flows, including redirect and state parameter handling
Injection & input handling
- SQL and NoSQL injection, including blind and time-based variants
- Cross-site scripting — reflected, stored and DOM-based
- Server-side template injection and expression language abuse
- Command injection and unsafe deserialisation
- XXE and SSRF, including cloud metadata service access
Business logic
- Workflow sequencing — skipping steps that gate payment or approval
- Price and quantity manipulation in transactional flows
- Race conditions on balance, quota and redemption operations
- Rate limiting on operations with real financial or reputational cost
- Abuse cases specific to what your application actually does
This is where scanners find nothing and testers find the most.
How the engagement runs
Scoping call — free, 45 minutes
We walk through your application, user roles, integrations and concerns. You get a fixed-price proposal within two working days.
Authorisation and preparation
Scope and authorisation signed by both parties. You provide test credentials for each role and a technical contact. If your host requires notification, we tell you.
Testing window
Testing proceeds against the agreed schedule. You receive a status update at the midpoint, and immediate notification of anything Critical.
Reporting
Draft report within five working days of testing completion. You review for factual accuracy before it is finalised.
Remediation support
A working session with your engineers to walk through findings and confirm the fixes you plan will actually close them.
Retest and closure
Once remediated, we retest the affected findings and reissue the report with updated status. Included, within six months.
What we need from you
Engagements that start well finish well. Having these ready before day one converts directly into more testing time.
- Target URLs for every environment in scope, and clear exclusions
- Two accounts per user role — the second is what makes cross-user access control testing possible
- Written authorisation from someone able to grant it for the systems in scope
- A technical contact reachable during the testing window
- Allowlisting for our testing IPs if a WAF would otherwise block testing, or a decision to test through it deliberately
- API documentation if the application has a significant API surface
A note on WAFs
Testing through a web application firewall measures the WAF, not the application. We usually recommend testing with our IPs allowlisted so we assess the code itself, then separately confirming the WAF blocks what it should. Testing only from behind the WAF produces a clean report and a false sense of safety.
Common questions
Will testing take our application down?
It should not, and we plan explicitly to avoid it. We exclude destructive and denial-of-service techniques unless you specifically ask us to test resilience. That said, testing does generate unusual traffic and can create test data in your system. We agree the window in advance and stay reachable throughout.
Do you need our source code?
Not necessarily. Black-box testing reflects an external attacker's view. Grey-box — where we have credentials and architectural context — finds more in the same time and is what we usually recommend. Full white-box with source access is worth it for high-assurance applications and is priced separately.
How often should we test?
Annually as a baseline, and after any significant architectural change — a new authentication system, a new payment flow, a major framework upgrade. Many compliance regimes require annual testing plus testing after significant change, which is a sensible standard regardless of whether you are certifying.
What if you find nothing serious?
That is a legitimate outcome and we report it plainly rather than padding the report with informational findings to justify the invoice. You get an attestation letter confirming the scope and dates tested, which is usually what you needed the test for anyway.
See what we would find in your application.
Claim one free verified finding, or book a scoping call for a fixed-price quote.