A WAPT, or Web Application Penetration Test, is the exercise in which security specialists attack a web application in a controlled way to find its vulnerabilities before somebody else does. It sounds like something only large enterprises need, and instead it concerns anyone running a customer portal, an e-commerce site, a SaaS platform, or even just a members' area on their website.

Here is an example that makes it concrete. A services company has a portal where customers download invoices and contracts. The page address ends with a number, something like "document=1045". A curious customer tries changing it to 1046 and finds themselves looking at another customer's invoice. No sophisticated hacker, no malware, just a missing access control. It is one of the most widespread vulnerabilities there is, and an automated scanner will rarely find it, because technically the page is working perfectly.

A WAPT exists to uncover exactly this kind of problem. And for a couple of years now it has carried documentary weight too: clients, public tenders and regulations such as NIS2 and the GDPR require proof that security has been verified, and an application penetration test report is one of the most convincing forms of evidence. Below you will find how a WAPT works, how it differs from a vulnerability assessment, which modes exist, what it checks in light of the OWASP Top 10:2025, and how to read the report.

What a WAPT is and what gets tested in a web application

What is a WAPT? A WAPT, or Web Application Penetration Test, is a security test in which specialist analysts simulate real attacks against a web application. The goal is to identify vulnerabilities, demonstrate whether and how they can be exploited, and indicate how to fix them, with a final report the company can use both to take action and as evidence towards third parties.

The scope of a WAPT is the application in all its parts: the interface the user sees, the back-end services, the APIs, the login and session management mechanisms, the controls over who can see and do what, the dialogue with the databases. The most common types are web portals with restricted areas, APIs connecting different systems, SaaS platforms used by multiple customers, online services and e-commerce sites.

Each has its own typical weak points. In SaaS platforms the key question is whether one customer's data genuinely stays separate from everyone else's. In e-commerce the focus is mostly on payments, carts and accounts. In APIs the classic risk is an endpoint designed for internal use being reachable from outside, or returning more data than it needs to. For APIs there is also a dedicated risk ranking, the OWASP API Security Top 10, which a good WAPT takes into account.

Why web applications in particular? Because they are exposed by definition. To attack an internal server you first have to get inside the network; to attack a web application a browser is enough. On top of that they are living software: they are updated often, they integrate third-party components, they are developed on tight timelines. Every release can open a new gap.

WAPT, vulnerability assessment and infrastructure penetration test: the differences

These three activities are often confused, and the confusion is expensive, because it leads people to believe they are protected having checked only one piece of the problem.

The vulnerability assessment identifies and evaluates potential vulnerabilities, often with the help of automated scanners: outdated software versions, missing patches, misconfigurations. It is fast, repeatable, inexpensive, and excellent as a periodic check. It does not always include controlled verification of whether vulnerabilities can actually be exploited and what their impact would be. Scanner results can also include false positives, which need checking.

The WAPT goes deeper into whether and how vulnerabilities can be exploited and what impact they could have. Analysts use automated tools too, but the bulk of the work is manual: they verify each flaw, combine it with others to build realistic attack scenarios, and measure the concrete impact. Vulnerabilities tied to the application's logic, such as the invoice example above, a cart that accepts negative quantities, or a payment flow that can be skipped, emerge almost exclusively this way.

The infrastructure penetration test, finally, looks at networks, servers, firewalls, VPNs and exposed services. It complements the WAPT: a hardened infrastructure can host an application full of holes, and a beautifully written application can sit on a badly configured server. Companies exposing critical applications usually run both.

WAPT black-box, grey-box and white-box: the three modes compared

WAPT modes differ in how much information the analysts receive before they start. Each simulates a different attacker.

Black-box WAPT: the perspective of someone arriving from the internet

In a black-box test the analysts start from nothing: no credentials, no documentation, just the application's address. Exactly like any attacker. They map the exposed surface, identify the endpoints, and look for vulnerabilities reachable from outside. It is the mode that answers the most instinctive question: what can someone who finds my application on the internet see and do?

Grey-box WAPT: what happens after login

In grey-box the analysts receive credentials for one or more users, for example a standard user and an administrator. This explores the part of the application behind the login, which is often where the most serious problems hide. The focus is access control. Can a standard user get into administrator functions? Can they read or modify another user's data? In the jargon these are called vertical and horizontal privilege escalation, and they are among the most frequent causes of data breaches.

White-box WAPT: testing with all the cards on the table

In white-box the analysts have full access to source code, documentation and architecture. It is the deepest mode and comes close to a security-oriented code review. It takes more time and more involvement from the development team. For most SMEs the combination of black-box and grey-box gives the best balance between risk coverage, timescales and cost, with white-box reserved for particularly critical applications or specific development phases.

The phases of a Web Application Penetration Test

A well-run WAPT follows a five-phase path, preceded by a preliminary step that often gets underestimated.

The preliminary step is defining the scope and the rules of engagement. The company and the analysts agree which applications to test, which environments, which user types, in which time window, with what limits and through which communication channels if something goes wrong. Written authorisation is also needed: attacking an IT system without the owner's consent is a criminal offence, and the authorisation document protects both parties. If the application is hosted by a provider, it is worth checking that their terms permit the test.

Then the work begins. The first phase is information gathering: the analysts study the application, understand how it works, and map the architecture, user flows, APIs and technologies in use. The second is vulnerability identification, with automated tools and manual analysis complementing each other. The third is in-depth exploration of the application, putting authentication, sessions, permissions and input handling under pressure. The fourth is exploitation, the controlled attempt to exploit the flaws found in order to demonstrate their real severity. The fifth is the report, which documents everything and sets out how to intervene.

A practical note on the test environment. Where a staging environment identical to production exists, that is the best place for the more invasive tests. If testing in production, it is wise to schedule the work during low-traffic hours, have a recent backup, and warn whoever monitors the systems, so the test is not mistaken for a real attack.

OWASP Top 10:2025: the vulnerabilities a WAPT goes looking for

What is the OWASP Top 10? It is the ranking of the ten most critical security risks for web applications, published by the OWASP foundation. It is the most widely used international reference for classifying vulnerabilities in penetration test reports and in supplier security questionnaires. The 2025 edition, presented in November 2025 and consolidated in January 2026, is the first update since 2021.

At the top of the list remains Broken Access Control, which in the 2025 edition also absorbs Server-Side Request Forgery. It is the category of the invoice example: permissions missing or bypassable. In second place come security misconfigurations, which were fifth in 2021, and the reason is intuitive: modern applications depend more and more on cloud, container and external service configurations.

Third place goes to one of the two new entries, software supply chain failures. It extends the old category of vulnerable and outdated components to include dependencies, build systems and distribution infrastructure. For anyone developing with dozens of open source libraries, this is anything but theoretical.

Then come cryptographic failures in fourth place and injection in fifth, a family ranging from SQL injection to cross-site scripting. Sixth is insecure design, seventh authentication failures, eighth software and data integrity failures, ninth logging and alerting failures. Closing the 2025 edition is the second new entry, mishandling of exceptional conditions: applications that behave insecurely when faced with an unexpected error, for example by showing technical details or leaving a transaction half-finished.

Why does it matter that the report follows this classification? Because everyone reads it the same way: the development team, the external supplier, the client's security lead, the auditor. A report aligned to the OWASP Top 10 slots into supplier qualification processes without friction.

The Top 10 helps classify risks, but it does not exhaust what a WAPT checks: the test must also consider the application's specific functions and risks.

When to request a WAPT: the moments when it pays off most

A WAPT delivers the most when it is tied to specific moments in the life of an application or of the company.

Before launch is the ideal moment. No customer data is exposed yet, fixes fit into the development cycle and cost far less. After every significant change is the second key moment, because a new feature or an integration can open a gap that was not there before. In these cases the test can concentrate on the parts affected, with reduced time and cost.

Then there are the commercial occasions. Many public tenders ask for evidence of security testing on the applications involved in the supply, and more and more private clients want a report before entrusting their data to a vendor. In both cases a recent WAPT report, with vulnerabilities described by category, severity and remediation status, is a ready-made attachment that saves weeks in qualification.

After an incident, the priority is containing the attack and reconstructing what happened through incident response and forensic analysis. A targeted WAPT can then help verify the vulnerabilities and the fixes applied.

How often should it be repeated? A good rule is at least once a year on critical applications, and in any case after every major release. Teams releasing very frequently do well to build lighter tests into the development cycle and reserve the full WAPT for major releases.

WAPT and compliance: the role of penetration testing in NIS2, GDPR and ISO 27001

The WAPT was born as a technical activity, but today it has a defined role in regulatory compliance too. The main rules on security and data require you to demonstrate that the measures adopted actually work, and the penetration test is one of the strongest forms of proof.

The GDPR, in Article 32, requires controllers and processors to adopt appropriate technical and organisational measures and, among them, a process for regularly testing, assessing and evaluating their effectiveness. A periodic WAPT can contribute to the verifications required by Article 32, where it is appropriate to the risks of the processing. The report documents the tests carried out and should be assessed together with the measures adopted and the fixes applied.

NIS2, transposed in Italy by Legislative Decree 138/2024, requires essential and important entities to adopt risk management measures that include vulnerability management and the assessment of the effectiveness of security measures. For many entities added to the NIS list in 2025, the deadline for adopting baseline security measures falls in October 2026, following the calendar tied to the communication received from ACN. A WAPT report, accompanied by the fixes and the retest, can be useful evidence to document the verifications carried out.

ISO 27001:2022 includes among its Annex A controls the management of technical vulnerabilities and security testing during system development and acceptance. In an audit, a WAPT report accompanied by the remediation plan and the retest documents the effectiveness of those controls very convincingly.

The WAPT report: how it is built and how to use it

The report is the real product of a WAPT: it speaks to two different audiences, and it does so in two parts.

The executive summary is for management: overall risk level, most serious vulnerabilities, intervention priorities, in language anyone can follow without being technical. The technical chapter is for the people who have to fix things: for each vulnerability it describes the assets involved, the relevant OWASP category and the severity of the vulnerability, possibly accompanied by a CVSS score, the demonstration of exploitability with the steps to reproduce it, and operational guidance on resolving it.

The report only earns its keep when the flaws get closed, though. It is best to start from the most serious and most easily exploitable vulnerabilities, assign an owner and a deadline to each, and track progress. Once the fixes are complete, the retest verifies that the mitigations work and produces a new report. With clients and in tenders it is often this second document that gets asked for, because it demonstrates the full cycle: problem found, problem fixed, fix verified.

Our WAPT: how we test SME applications

We designed our WAPT service for companies without an in-house security team, who need two very concrete things: knowing where to put their hands, and having a report to show clients and contracting authorities.

We put web portals, APIs, SaaS platforms, online services and e-commerce sites to the test, meaning the applications where a flaw translates immediately into unauthorised access, exposed customer data, fraud or compromised transactions. We work in two modes. With black-box we look at your application through the eyes of someone arriving from the internet without credentials, and we tell you what they can find out. With grey-box we come in with a standard user's credentials and check whether that role can push beyond the permissions it should have, identifying privilege escalation risks and pointing precisely to where you need to act.

We build the scope with you, based on how many platforms you want to include and how many user types need checking: every role, from administrator to guest, is tested separately. The work is carried out entirely remotely, with the same depth as an on-site test, and a dedicated expert follows it from the first exchange of information to delivery. We commit to delivering the report in 10 to 12 working days per application, from the moment the information and access needed for the test are available.

What you receive is a complete technical report: an executive summary to get the overall picture immediately, and a technical section with the assets involved, vulnerabilities mapped to OWASP Top 10 categories, an assessment of their severity, and operational guidance for fixing them. If you want, once you have applied the fixes we run a retest on the corrected vulnerabilities and deliver a report documenting the outcome of those checks. And since a WAPT is also a piece of NIS2, GDPR and ISO 27001, our Lead Auditors can connect the results to your compliance path. This is a common combination for companies in the IT and software sector.

Want to know how solid your application really is? Get in touch to request a WAPT and define the scope together.

Frequently asked questions about WAPT

What is a WAPT in simple terms?

It is a test in which security experts attack your web application in a controlled way, with your permission, to find the flaws before a real attacker does. At the end you receive a report explaining what they found, how serious it is and how to fix it. It is the most direct way to know how secure an application is in the real world.

What is the difference between black-box and grey-box WAPT?

In black-box the analysts start with no credentials and simulate an external attacker. In grey-box they receive credentials for one or more users and check what happens after login, for example whether one user can see other people's data or use restricted functions. The two modes complement each other, and together they cover most of an application's risks.

How long does a WAPT take?

It depends on how many applications and user roles fall within the scope, and how complex the application is. In our service we deliver the report in 10 to 12 working days per application, from the moment the information and access needed for the test are available. The work is carried out entirely remotely.

How often should a WAPT be done?

Good practice is at least once a year on important applications, and after every significant change, such as new features, architectural changes or new integrations. Some clients and tenders ask for reports with a recent date, and that is worth factoring into your planning.

Can a WAPT bring the application down?

A professional WAPT follows rules of engagement agreed on environments, timing and limits. Analysts use controlled techniques to demonstrate vulnerabilities while limiting the impact on operations. Where a staging environment identical to production exists, the more invasive tests are run there. A recent backup and a heads-up to whoever monitors the systems complete the preparation.

Is a WAPT mandatory under NIS2?

NIS2 requires risk management measures that include vulnerability management and verification of the effectiveness of security measures, leaving the choice of tools to the company. A WAPT is one of the most effective ways of demonstrating this on exposed web applications, and a report with remediation is solid evidence in the event of an ACN check or a client request.

What is the OWASP Top 10:2025?

It is the updated ranking of the ten most critical risks for web applications, published by the OWASP foundation. Broken Access Control is in first place, and the new entries include software supply chain failures and the mishandling of exceptional conditions. It is the most widely used standard for classifying vulnerabilities in penetration test reports.

What happens after the report is delivered?

Your development team, or the supplier who built the application, fixes the vulnerabilities following the report's priorities and guidance. Then you can request the retest, which verifies the fixes and produces a new report. That second document states whether the vulnerabilities subjected to retest are resolved, and it is often the one clients and contracting authorities want to see.