Authentication & session
Login, reset, MFA bypass, session fixation, token reuse, OAuth / SSO gaps, and account-takeover chains against a second test identity.
MFA bypassOAuthJWT
Home / Services / Web application VAPT
Web application VAPT
Web penetration testing for UK product teams.
Manual-first testing of the web applications your UK customers log into — authorisation, session, injection, business logic — written up for Cyber Essentials Plus, ISO 27001 and enterprise due diligence.
Coverage
Beyond a scanner-shaped OWASP Top 10
Access control
IDOR / BOLA, function-level auth, privilege escalation, multi-tenant isolation, hidden admin.
IDORTenancyBFLA
Injection & XSS
SQL / NoSQL, command injection, SSTI, XXE, reflected / stored / DOM XSS, second-order bugs.
SQLiXSSSSTI
Business logic & request integrity
Workflow skip, races, price and voucher abuse, CSRF, upload, SSRF, smuggling where the stack allows it.
LogicCSRFSSRF
Most UK SaaS products do not fail because of a 2014 SQLi. They fail because user 2 can read user 1’s invoices by changing a UUID they were never meant to know. Typical window: 3–5 working days. Written CMA 1990 authorisation first. Re-test included.
Why it matters
What actually breaks UK web applications
It is almost never the exploit you rehearsed for
The vulnerabilities that end up in our reports are rarely the ones a scanner shouts about. They are authorisation gaps: an invoice ID that increments, a tenant identifier trusted from the request body, an admin endpoint that checks whether you are logged in but never checks who you are. A scanner cannot find these because it has no idea that user A should not see user B’s data. It has no model of your business. We build one on day one, then attack it.
Two identities, or it is not an authorisation test
Every engagement runs with at least two accounts at the same privilege level and, where the product has roles, one of each role. That is the only way to prove horizontal and vertical access-control failures rather than guess at them. If you can only give us one login, say so at scoping and we will tell you honestly which findings become unprovable — we would rather narrow the claim than pad the report.
Business logic is where the money leaks
Payment flows that can be replayed, vouchers that stack, quotas that reset when a request is sent twice, multi-step workflows that can be entered at step three. None of this shows up in a CVE feed. It comes from reading the product like an attacker with a commercial motive, which takes time and a human, and is the reason this work is not sold by the scan.
The report has to survive a procurement review
A UK enterprise buyer, an ISO 27001 auditor and your own developers all read the same document and want different things from it. So it is written for all three: an executive summary with impact in business terms, a technical section with exact reproduction steps, CVSS v3.1 scoring, and a control mapping that says plainly where a finding does and does not evidence a framework requirement.
If you are being asked for a penetration test by a customer, an insurer or an auditor, the thing being asked for is evidence. Evidence means a named tester, a defined scope, reproducible findings and proof the issues were fixed. That is what this engagement produces.
How it runs
The engagement, step by step
Scope and authorisation
We agree the exact hosts, applications and identities in scope, the testing window, rate limits, and what is explicitly out of bounds. You sign a written authorisation under the Computer Misuse Act 1990 and we counter-sign. No packet is sent before that document exists.
Environment and identities
You provision two or more test accounts per role, ideally in staging with production-like data volumes. We confirm we can reach everything in scope and that your monitoring will not page someone at 02:00 because of us.
Mapping the application
Every route, parameter, role and state transition, walked by hand. We build a model of who is supposed to be able to do what. This map is what makes the authorisation testing meaningful, and you get a copy of it.
Manual testing
Authentication and session handling, access control against the second identity, injection, file handling, business logic, and the request-integrity issues the stack allows. Tooling runs alongside to cover breadth; it never decides what counts as a finding.
Proof, bounded
Each confirmed issue gets a minimal, repeatable proof: a request, a screenshot, a short script. We take enough to be undeniable and no more. We do not bulk-extract your customer data to make a point.
Report and re-test
Draft report, a walkthrough call with your engineers, then the final document. When you have patched, we re-test every confirmed finding, at no extra cost, and issue a statement of what is now closed.
Deliverables
What lands on your desk
Executive summary
Two pages a non-technical director can read: what was tested, what the real business exposure is, what it will take to fix, and whether we would sign this off. Written to be lifted straight into a board pack or a customer response.
Technical findings
Per finding: severity and CVSS v3.1 vector, affected endpoints, exact reproduction steps a developer can follow without calling us, evidence, impact, and a specific remediation — not “implement input validation”.
Control mapping
Each finding mapped to OWASP ASVS, ISO/IEC 27001 Annex A and NCSC CAF outcomes where the mapping is honest. Where a finding evidences nothing in particular, we say so rather than inventing a reference.
Re-test and attestation
A re-test of every confirmed finding after you patch, included in the original fee, plus a letter of attestation on request stating scope, dates, tester and outcome — the document your customer’s procurement team is actually asking for.
Scoping
What we need from you to start
- The URL of the environment to test — staging is fine, and usually better, if the data and configuration mirror production.
- Two accounts per role, plus one account that should have no access at all, so isolation can be proven.
- A short walkthrough of what the product does and which flows carry money, personal data or contractual obligations.
- Any known issues or areas you already suspect. Telling us saves days and does not reduce what we look at.
- Rate-limit, WAF and alerting arrangements, so we can agree whether to test through them or with them relaxed.
- A named technical contact who can answer a question within a working day if the environment breaks.
If you do not have a staging environment, we can test production under tighter constraints — read-only where possible, agreed hours, no destructive payloads. It changes what can be proven, and we will tell you what before you commit.
UK compliance
Where this sits in a UK compliance programme
Cyber Essentials Plus
CE+ is an audited baseline check, not an attacker simulation. A penetration test does not replace it and it does not replace a penetration test. Where the two overlap — patching, access control, configuration — our findings give you the evidence to fix things before the CE+ assessor arrives.
ISO/IEC 27001
Supports Annex A controls on secure development, application security requirements and technical vulnerability management. The report is written so an auditor can trace a finding to a control, a remediation and a verification date.
UK GDPR, Article 32
Article 32 requires a process for regularly testing and evaluating the effectiveness of your technical measures. An independent test with a re-test cycle is one of the cleanest ways to evidence that to the ICO or to a customer’s DPO.
PCI DSS v4
Requirement 11.4 still expects application-layer penetration testing at least annually and after significant change. If you are a UK merchant taking card data through a hosted page, the scope is usually narrower than you fear — we will tell you that rather than sell you the larger test.
Questions
What UK buyers ask before signing
It depends on the number of roles, the number of distinct workflows and whether an API is in scope — not on the number of pages. Most focused UK web application engagements run three to five working days. You get a fixed quote in pounds sterling after a thirty-minute scoping call, before any commitment.
Three to five working days of testing for a focused application, plus two to three days for reporting. Larger multi-tenant platforms with several roles run longer. We agree the window at scoping and we do not start until the authorisation letter is signed.
Staging by default, provided it mirrors production configuration and has realistic data. Production testing is possible under agreed constraints — restricted hours, no destructive payloads, bounded proof — and we will be explicit about which findings become harder to prove that way.
It should not. We agree rate limits in advance, avoid denial-of-service payloads unless you specifically ask for them in writing, and keep a named contact reachable throughout. If something does degrade, we stop and tell you immediately rather than finishing the day quietly.
Yes. Once you have patched, we re-test every confirmed finding and issue a statement of what is closed. It is in the original fee, not a separate invoice, because a test without a re-test does not prove anything was fixed.
No, and we will not imply otherwise. If your tender mandates CREST or NCSC CHECK membership — common for CNI and much of the public sector — you should use a member firm. For UK SaaS, fintech and product companies answering enterprise due diligence, what you need is a manual test with reproducible proof and an honest control mapping, and that is what this is.
Related
Engagements that usually run alongside
01
02
03
API security testing
REST and GraphQL: object-level authorisation, mass assignment, rate limits, schema exposure.
02
Mobile app VAPT
Android and iOS clients, and the API behind them where the real risk usually sits.
03
Security audit & reporting
The write-up an auditor accepts and a developer can act on, with a re-test to close it out.
Ready to scope a UK engagement?
A thirty-minute call. Assets, timeline, a quote in pounds sterling.
Request a quote