Penetration Testing
Web Application Penetration Testing Services
Web application penetration testing is a manual, authorised attack on your website or web app that finds the flaws a real attacker would exploit, from broken access control and injection to business logic abuse. As a PCI SSC-approved QSA company, we write every web app penetration testing report to stand up as PCI DSS 11.4 and ISO 27001 evidence.
Prefer to talk? Call +44 161 523 5276
- Manual OWASP-based testing, not just scans
- Retest of remediated findings available
- Reports mapped to PCI DSS 11.4 and ISO 27001
Trusted by banks, payment providers and global brands
On this page
- Web application security testing: what's included
- OWASP penetration testing: what we test for
- Web application penetration testing at a glance
- How much does web application penetration testing cost?
- Which tools do web application testers use?
- Black box, grey box or white box web application testing?
- Web application penetration testing checklist
- What are the stages of a web application penetration test?
- Why choose Sovereign Secure for web application penetration testing?
- Frequently asked questions
Overview
What is web application penetration testing?
The short answer
Web application penetration testing is a manual, authorised attack on a website or web app that shows which flaws a real attacker could exploit. A typical test works through every user role against the OWASP Top 10, covering access control, authentication, sessions, injection and business logic, plus the APIs the application calls.
A web application penetration test is a controlled, in-depth assessment of your web application. We simulate the tactics a real attacker would use to reach your data, taking each user role in turn and probing authentication, access control, input handling and the underlying configuration.
The aim is simple. Find the weaknesses before someone else does, prove which ones are genuinely exploitable, and give your developers a clear path to fixing them. We test authenticated and unauthenticated views, and we exercise the APIs the application relies on where they are in scope. If you have done threat modelling or have design notes, share them at scoping so testing targets your trust boundaries and abuse cases.
Web application security testing can mean anything from an automated scan, known as dynamic application security testing (DAST), to a full manual test. The difference that matters is depth: a scanner checks for known patterns, while a manual test works through every role, workflow and permission the way a person would. That is where the serious findings usually are. For a brochure or e-commerce site built on WordPress, Shopify or Magento, see website penetration testing.
As a PCI Qualified Security Assessor company, we write findings the way assessors expect to read them. A web application test done for security therefore also serves as evidence for PCI DSS penetration testing under Requirement 11.4, and for ISO 27001:2022 Annex A 8.8 and 8.29 (see penetration testing for ISO 27001).
Price depends mainly on the number of user roles, functions and workflows in scope. Our guide to penetration testing costs shows how scope drives price, and you can request a fixed-price web application testing quote before any work starts. New to testing? Our guides to what penetration testing is and the types of penetration testing show where this test fits.
What's included
Web application security testing: what's included
Every web application engagement covers the following as standard.
- 01
OWASP Top 10 coverage
Testing across the current OWASP Top 10:2025, from broken access control (now including server-side request forgery) and injection through to insecure design and mishandling of exceptional conditions.
- 02
Authenticated, multi-role testing
We test with credentials for each role you provide, so we can find the access-control flaws that only appear once a user is logged in.
- 03
Business logic testing
Manual abuse of workflows, pricing, quantity limits and multi-step processes that scanners cannot understand.
- 04
Session and authentication review
Login, multi-factor authentication, password reset and session handling, checked for the weaknesses that lead to account takeover.
- 05
API and integration checks
The endpoints and third-party integrations the application calls, tested alongside the front end where they fall in scope.
- 06
Manual verification of every finding
We confirm each issue by hand and record clear reproduction steps, so you are not chasing false positives.
- 07
Remediation guidance
Practical, developer-focused advice for each finding, prioritised by risk.
- 08
Retest
A retest of remediated findings, scoped in your fixed-price proposal, with the report updated to show them closed.
What we test for
OWASP penetration testing: what we test for
OWASP penetration testing means testing a web application against the risks in the OWASP Top 10, using the methods in the OWASP Web Security Testing Guide (WSTG), with the OWASP Application Security Verification Standard (ASVS) as the measure of what good looks like. Every web application test we run follows that model, and the categories below map to it. For a plain-English explanation of each risk, see our OWASP Top 10 glossary entry.
Injection
Untrusted input reaching an interpreter as part of a command or query, letting an attacker read, alter or destroy back-end data.
- SQL and NoSQL injection
- OS command injection
- LDAP and XML injection
- Server-side template injection
- Input validation and encoding gaps
Broken access control and IDOR
Missing or flawed authorisation that exposes data and actions meant to be off-limits, including other users’ records.
- Insecure direct object references
- Horizontal and vertical privilege escalation
- Parameter and identifier tampering
- Forced browsing to hidden functions
- Unprotected or over-permissive endpoints
Broken authentication and sessions
Weak identity and session handling that opens the door to account takeover and impersonation.
- Weak or default credentials
- Missing or bypassable multi-factor authentication
- Insecure session handling and fixation
- Password reset and recovery flaws
- Brute-force and credential-stuffing exposure
Cross-site scripting
Malicious scripts injected into pages other users trust, used to steal sessions or act as the victim.
- Reflected cross-site scripting
- Stored cross-site scripting
- DOM-based cross-site scripting
- Unsafe output rendering
- Content security policy gaps
Business logic abuse
Legitimate features abused in ways the application never intended, often invisible to automated tools.
- Workflow and sequence bypass
- Price, quantity and discount manipulation
- Race conditions
- Insufficient limits on sensitive actions
- Abuse of trust between steps
Security misconfiguration
Insecure defaults, verbose errors and exposed components that hand an attacker an easy foothold.
- Default credentials and sample content
- Verbose errors and stack traces
- Misconfigured security headers and CORS
- Exposed admin panels and directories
- Unpatched components and dependencies
Web application penetration testing at a glance
| Aspect | Typical web application penetration test |
|---|---|
| Scope | One web application or portal, every user role you provide and, where in scope, the APIs behind it |
| Approach | Grey box by default (credentials for each role and some documentation); black box or white box on request |
| Typical effort | About 4 to 10 tester-days for a scoped engagement, going by the published prices from UK providers we reviewed in September 2026; small packaged tests take less |
| Standards | OWASP Top 10, OWASP WSTG and OWASP ASVS, reported for PCI DSS 11.4 and ISO 27001 Annex A 8.8 and 8.29 |
| Deliverables | Executive summary, technical findings with reproduction steps and CVSS ratings, remediation advice and a debrief call |
How much does web application penetration testing cost?
In the published prices from UK providers we reviewed in September 2026, a single web application penetration test ranged from £1,650 for a basic fixed package to £10,000 or more for a scoped engagement. The price follows the number of tester-days your application needs, and these drivers set that number:
| Cost driver | Why it changes the price |
|---|---|
| User roles | Each role is tested against the others for access-control flaws, so more roles means more days |
| Functions and workflows | Checkouts, approvals and other multi-step processes need manual business logic testing |
| Authenticated testing | Testing behind the login finds most serious flaws, but takes longer than an unauthenticated test |
| APIs behind the app | Endpoints the front end calls, and any it does not, add testing time when they are in scope |
| Environments and tenants | Testing staging and production separately, or several tenants, adds days |
These ranges are a small sample of published market prices, not Sovereign Secure prices. Our penetration testing cost guide shows the ranges for every test type, and the web application testing quote form turns your scope into a proposal.
Which tools do web application testers use?
In web pentesting, testers commonly use an intercepting proxy such as Burp Suite or the open-source ZAP to capture, replay and change every request the application sends, alongside browser developer tools, scripted requests and scanners that check for known issues.
Tools find candidate issues quickly, but they cannot tell that one customer should never see another customer’s order, or that a discount should not apply twice. That is why the core of a web application test is manual: a tester works through each role and workflow by hand and confirms every finding before it goes in the report.
Black box, grey box or white box web application testing?
Grey box is the default for most web application tests: you provide credentials for each role and some documentation, so the time goes on depth rather than guesswork. Black box models an outside attacker with no inside knowledge, and white box adds source code, which pairs well with a source code review. Our guide to white box penetration testing compares it with black and grey box testing.
Web application penetration testing checklist
A web application penetration test should check at least the areas below. Each maps to the OWASP Top 10:2025 and to the OWASP penetration testing scope above, so you can use the list to compare proposals or brief your developers before a test.
| Area | What the tester checks | OWASP Top 10:2025 |
|---|---|---|
| Access control | Each role tested against the others for privilege escalation, including insecure direct object references (IDOR) and forced browsing | A01 Broken Access Control |
| Configuration | Security headers, CORS, verbose errors, default content and exposed admin pages | A02 Security Misconfiguration |
| Components | Outdated frameworks, libraries and plugins with known vulnerabilities | A03 Software Supply Chain Failures |
| Data protection | TLS settings and how sensitive data is protected in transit and at rest | A04 Cryptographic Failures |
| Input handling | SQL, NoSQL and command injection, template injection and cross-site scripting (XSS) | A05 Injection |
| Business logic | Workflow bypass, price and quantity tampering, race conditions and missing limits on sensitive actions | A06 Insecure Design |
| Authentication and sessions | Login, multi-factor authentication, password reset, session expiry and fixation | A07 Authentication Failures |
| Integrity | Unsafe deserialisation, unsigned updates and data the server trusts without checking | A08 Software or Data Integrity Failures |
| Logging | Whether failed logins and access-control failures are logged and alerted on | A09 Security Logging and Alerting Failures |
| Error handling | Errors and unexpected states that fail open, leak data or crash the application | A10 Mishandling of Exceptional Conditions |
How it works
What are the stages of a web application penetration test?
- 1
Scoping
We agree the application, user roles, environment and rules of engagement in writing, then fix the price before any testing starts. Our checklist on how to prepare for a penetration test covers your side.
- 2
Reconnaissance and mapping
We map the application, its functions and its attack surface across every role you provide.
- 3
Testing
Manual testing backed by professional tooling, covering the OWASP Top 10, business logic and access control. Critical findings are flagged the day we confirm them.
- 4
Reporting
You receive an executive summary and a full technical report with reproduction steps, CVSS ratings and remediation advice.
- 5
Debrief
A walkthrough call with your team to talk through the findings, the risk and the fixes.
- 6
Retest
Once you have remediated, we retest the fixed findings and reissue the report showing them closed.
Every test follows the five stages of penetration testing: planning and reconnaissance, scanning, gaining access, maintaining access, and analysis and reporting.
Why Sovereign Secure
Why choose Sovereign Secure for web application penetration testing?
Established in 2012, we deliver PCI, ISO and Cyber Essentials work for banks, payment processors, card manufacturers and fast-growing companies.
Read client testimonials →- Findings are written with your QSA audit in mind. We are a QSA company, so the evidence lines up with what assessors ask for.
- Manual testing by hand, not a scan report with a cover page.
- Fixed scope and price agreed before we begin, with no hourly billing.
- A retest of remediated findings can be scoped into your fixed-price proposal.
FAQ
Frequently asked questions
Can't find your answer? Call us on +44 161 523 5276 or send us a message.
How long does a web application penetration test take?
Most single applications take around one week of testing, depending on size, number of roles and complexity. We confirm the timeline during scoping and escalate any critical findings the day we confirm them.
Will testing disrupt our live environment?
We test against staging or a dedicated test environment wherever one exists. Where production is the only option, we agree rules of engagement in advance: no denial-of-service techniques, no destructive payloads and defined testing windows.
Does this satisfy PCI DSS Requirement 11.4?
Yes. Requirement 11.4.1 says your testing methodology must include application-layer penetration testing, and 11.4.2 and 11.4.3 require internal and external tests to that methodology. Because we are a PCI QSA company, the report is written to serve directly as your evidence. See PCI DSS penetration testing for how the full 11.4 scope fits together. It also supports ISO 27001:2022 Annex A 8.8 and 8.29.
How do you do web application penetration testing?
A tester agrees the scope and user roles, maps the application, then works through each role by hand against the OWASP Top 10 and the business logic, confirming every finding before writing the report. Our guide to penetration testing methodology explains each stage, and the checklist above lists what a test should cover.
What is the difference between a web application pen test and a vulnerability scan?
A scan is automated and finds known issues such as missing patches and weak headers. It cannot log in as each role, abuse a checkout workflow or spot one customer reading another customer’s records. A manual penetration test does, which is why PCI DSS and ISO 27001 auditors treat them differently. Many clients pair annual testing with ongoing vulnerability scanning.
What do you need from us to get started?
A short scope form or call, the application URL, test credentials for each user role, and a point of contact. For authenticated testing we ask for at least one account per role, typically an ordinary user and an administrator.
How often should we test?
At least annually, and after any significant change to the application or its infrastructure. Frameworks such as PCI DSS require testing at least once every 12 months and after significant changes.
Last reviewed October 2026 by the Sovereign Secure assessment team.
Related services
- API penetration testingAPI penetration testing services for REST, GraphQL and SOAP web services, tested against the OWASP API Security Top 10 by a PCI QSA company. Get a quote.
- Source code reviewSecure code review services UK: manual source code security review plus static code analysis (SAST), mapped to OWASP and PCI DSS 6.2. Get a quote.
- PCI DSS penetration testingPCI compliance penetration testing to PCI DSS Requirement 11.4 by a QSA company: internal, external, application and segmentation pen tests with ROC-ready reports.
- Penetration testing costPen test cost in the UK for 2026: published day rates and penetration testing price ranges by test type, what drives cost, and how to get a fixed quote.
- Penetration testing quoteScope your test types and asset counts and get a fixed-price penetration testing proposal.
Free consultation
Talk to an assessor
We aim to reply within one working day, and send a fixed quote once your scope is confirmed.
- PCI SSC-approved QSA, QPA, CPSA, P2PE and 3DS assessors
- IASME-licensed Cyber Essentials certification body
- Clients across the UK, US, Europe, Middle East and Asia since 2012
“The Cyber Security Services were delivered on time and price was competitive.”
Call +44 161 523 5276
Email [email protected]