Every web application you run is a door into your business, and most of them hold something worth stealing: customer records, payment details, logins, internal data. A web application penetration test is how you find out whether those doors actually lock before someone tries to force them.

This guide explains what a web application penetration test involves, the different types you can commission, the phases a good tester works through, what shapes the cost, and how to pick a provider you can trust. If you already know the theory and just want the test itself, our web application penetration testing service covers that.

Before we continue, web application security has its own extensive vocabulary. If a term here is new to you, you should check out our cybersecurity glossary.

What is web application penetration testing?

A web application penetration test, often shortened to a web app pentest, is a controlled cyberattack on your application conducted by a professional tester. The tester, sometimes called an ethical hacker, looks for weaknesses the same way a criminal would, then writes up what they found and how to fix it. The point is to do that in a safe, agreed way, so you learn where you are exposed without any real harm being done.

Depending on the type of test, the tester will try to mimic a genuine attack as closely as possible. That gives you an honest picture of how your application would hold up against someone with bad intentions, rather than a tidy checklist that looks reassuring on paper. Once the work is done, the tester grades each vulnerability by how serious it is, and that grading matters, because it tells your development team what to fix first when they cannot fix everything at once.

You will sometimes see this sold as vulnerability assessment and penetration testing, or VAPT. A vulnerability assessment is mostly automated and casts a wide net to flag known issues, while a penetration test goes further, with a person actively trying to exploit those issues to see what an attacker could really achieve. The two work well together, and many web app tests include both. For a wider view of testing across networks and infrastructure as well as applications, see our guide to penetration testing.

Why web application security matters

Web apps are a favourite target for a simple reason: they are exposed to the internet by design, and they often sit right next to valuable data. A flaw in a login form or a poorly checked file upload can hand an attacker a route to information they were never meant to see.

Regular testing lets you find and patch those flaws before anyone else does. It also keeps you on the right side of standards such as GDPR, PCI DSS and ISO 27001, which expect organisations to test the systems that handle personal or payment data. Meeting those expectations protects your customers, and it protects you from the fines and reputational damage that tend to follow a breach.

The main types of web application penetration test

There is no single kind of web app test. Which one fits depends on your goals, your budget, and how much you want the tester to know before they start. Most engagements fall into one of three approaches, defined by how much information the tester is given.

Black box testing

The tester starts with no inside knowledge of your application, only what any outsider could find. This is the closest match to a real attack from a stranger, since a genuine attacker usually begins with nothing. It shows your exposure from the outside well, though it can miss deeper issues simply because time runs out before the tester reaches them.

White box testing

The opposite arrangement. The tester gets full access, including source code, architecture notes and credentials. With everything in view, they can examine the application thoroughly and find flaws a black box test might never reach. It takes more time to do properly, but it gives you the most complete result.

Grey box testing

The middle ground. The tester works from limited information, often a standard user login, which lets them probe the application the way a logged-in customer or a rogue insider might. For many businesses this is the practical choice, since it balances realism against depth without the full cost of a white box engagement.

The phases of a web application penetration test

No two tests run in exactly the same order, but most follow a recognisable set of phases. Knowing them helps you understand what you are paying for and what your team will need to provide.

Planning and reconnaissance

The test starts with scope. You and the tester agree what is being tested, what is off limits, and what a good outcome looks like. The tester then gathers information about the application, such as how it is built, what technologies it uses and where a user can interact with it. Strong reconnaissance shapes everything that follows.

Scanning and vulnerability detection

Next comes a mix of automated tools and manual checks to map the application’s weak points. Scanners are quick at spotting known problems such as outdated components, weak configuration or exposed data. There is deliberate overlap with reconnaissance here, since one feeds the other.

Exploitation

This is where the tester stops looking and starts doing. Using the weaknesses found so far, they attempt to break in, then see how far they can get. A common step is privilege escalation, where a small foothold is turned into much wider access by chaining several minor flaws together. Exploitation is what separates a real penetration test from a simple scan, because it shows genuine impact rather than theoretical risk.

Post-exploitation and clean-up

Once inside, the tester assesses what an attacker could actually reach and how long they could stay unnoticed. They then withdraw carefully, removing any test accounts or changes so your application is left exactly as they found it.

Reporting and remediation

The report is the part that earns its keep. A good one lists every vulnerability in order of severity, explains the business impact of each, and gives clear, practical advice on how to fix it. Your developers know the code better than any outside tester, so the aim is to hand them a prioritised map they can act on quickly, not to rewrite your application for them.

Common web application vulnerabilities and the OWASP Top Ten

When people talk about the most dangerous web application flaws, the reference point is almost always the OWASP Top Ten. OWASP, the Open Worldwide Application Security Project, is a non-profit that publishes a regularly updated list of the ten most critical risks to web applications. Developers, auditors and standards such as PCI DSS all lean on it, so a decent test will check your application against it.

The current edition is the OWASP Top Ten 2025, released in late 2025.

Broken Access Control stays at the top, covering flaws that let someone reach data or perform actions they should not be allowed to. Security Misconfiguration climbed to second, pushed up by insecure defaults and misconfigured cloud services. The 2025 list also introduced Software Supply Chain Failures, which covers risks that arrive through third-party libraries and build pipelines, and Mishandling of Exceptional Conditions, which looks at how an application behaves when something goes wrong. Familiar risks such as injection, which now includes cross-site scripting, and cryptographic failures remain on the list further down.

For a full breakdown of each category, our guide to the OWASP Top Ten goes through all ten in plain terms.

How much does a web application penetration test cost?

Cost is the question everyone wants answered first, and the honest reply is that it depends. The main factors are the size and complexity of your application, how many user roles and features need testing, and the type of test you choose. A small brochure site with a contact form sits at one end of the range, while a large application with several logins, payment handling and third-party integrations sits at the other.

Because of that spread, a fixed price quoted before anyone has looked at your application is usually a warning sign. A reputable provider will want a short scoping conversation first, then give you a firm quote based on what the test actually needs. That protects you from paying for coverage you do not need, and from a cut-price test that quietly skips the parts that matter.

Misconceptions worth clearing up

“The testers will fix the problems they find.”

They can, but it is rarely the best use of their time or your money. Your own developers understand your code far better than an outside tester, so they can usually patch a documented issue faster and more affordably than a third party could. The tester’s job is to find the problems clearly and explain the fix.

“Only big companies need it.”

If your application has users, you are responsible for their data, whatever your size, and attackers do not check your headcount before probing your login page. A smaller budget changes how you test, not whether you should, and a good provider will help you find an approach that fits what you can spend.

“One test and you are covered.”

Unfortunately, a test is a snapshot of a single moment. Code changes, dependencies age and new attack techniques appear, so a clean report from last year says little about today. Testing once a year is a sensible floor, with an extra test after any major change such as a new payment flow or a large release.

“An automated scan is enough.”

Scanners are useful and fast, but they only catch what they have been told to look for. They miss business logic flaws, chained attacks and anything that needs a person to reason about how your application really works. A scan is a good start, not a replacement for a proper test.

How to choose a web application penetration testing provider

Once you know you need a test, the next question is who should run it, and a few due diligence checks will save you from wasting money and time on a weak provider.

In the UK, look for CREST accreditation. CREST assesses providers and testers against recognised standards for skill and conduct, which means a CREST-accredited firm has been independently checked rather than simply claiming to be good. You can also use the NCSC’s CHECK scheme, which lists providers approved to test systems of national importance. Beyond the badges, ask how they scope the work, what their reports actually look like, and whether you can speak to the tester rather than only a salesperson.

Fortifi’s testers are CREST-qualified, and every engagement starts with proper scoping rather than a templated quote. When you are ready to test your application, our web application penetration testing service explains how we work and lets you book a scoping call.

Next Steps

Web application security is not a one-off task or a box to tick for an auditor. It is an ongoing habit that keeps the data your customers trust you with out of the wrong hands. A regular web application penetration test, run by people who know what they are doing, is one of the more reliable ways to build that habit.

If you would like to talk through the right test for your application, our CREST-accredited team is happy to help.