In short: A web application penetration test is an attempt by testers to find out which weaknesses in your application can actually be exploited, and what that would give an attacker. OWASP's Application Security Verification Standard (ASVS) 5.0 is the usual checklist: 17 areas, from how the application handles untrusted input to authentication, access control, file handling and logging, at three levels of depth. Most applications should aim for Level 2.
What is a web application penetration test?
NIST's glossary describes penetration testing as a method in which testers target an application's components, or the application as a whole, to find out whether its vulnerabilities can be exploited to compromise the application, its data or its environment. The word that matters is "exploited". A test does not stop at listing what might be wrong; it shows what an attacker could actually do with it, and how to fix it.
For a web application, that means the testers work against the running application: its pages, its API, its sign-in, and everything a user or an attacker can send to it.
Why OWASP ASVS 5.0
A test needs a definition of "secure" to test against. The OWASP Application Security Verification Standard defines security requirements for web applications and services, and version 5.0.0 was released on 30 May 2025. It describes the security outcomes the application itself must achieve, rather than how it should be built, which makes it a good fit for testing: each requirement is something a tester can check.
Using a published standard also makes the result comparable. A finding mapped to an ASVS requirement means the same thing to your developers, your auditors and the next tester.
What the test covers
ASVS 5.0 groups its requirements into 17 chapters. In plain words, from the standard's own chapter introductions:
| Chapter | What the test checks |
|---|---|
| V1 Encoding and Sanitization | How untrusted data is processed, so that it is never interpreted as code or commands (the family of injection flaws) |
| V2 Validation and Business Logic | That input matches what the business expects, that business flows run in order and cannot be skipped, and that limits stop automated abuse |
| V3 Web Frontend Security | Attacks carried out through the browser side of the application |
| V4 API and Web Service | Security settings and mechanisms for APIs used by browsers and other clients, such as JSON, XML or GraphQL |
| V5 File Handling | Uploaded and stored files, which can lead to denial of service, unauthorised access and storage exhaustion |
| V6 Authentication | Confirming who a user or device is, resisting impersonation, and protecting passwords from recovery or interception |
| V7 Session Management | That sessions are unique, cannot be guessed or shared, and end when no longer needed |
| V8 Authorization | That access is granted only to permitted users, services and clients, on the principle of least privilege |
| V9 Self-contained Tokens | Tokens such as JSON Web Tokens (JWTs) and SAML assertions, whose integrity and context must be validated |
| V10 OAuth and OIDC | Delegated authorisation and sign-in through OAuth and OpenID Connect |
| V11 Cryptography | The use of cryptography: sound choices, and systems that fail securely |
| V12 Secure Communication | Data in transit, between users and the backend and between internal services |
| V13 Configuration | Secure defaults for an internet-facing application, across development, build and deployment, including preventing data leakage |
| V14 Data Protection | What sensitive data needs protecting and how, including on users' devices |
| V15 Secure Coding and Architecture | General design and coding practices that application security depends on |
| V16 Security Logging and Error Handling | Logging of security events such as sign-ins and access decisions, for detection and investigation, and failing securely |
| V17 WebRTC | Real-time voice, video and data exchange, where the application uses it |
Not every chapter applies to every application. ASVS itself suggests leaving out what is not used, such as GraphQL or WebSockets, so the scope of a test follows what your application actually does.
How deep the test goes: the three levels
ASVS has three verification levels, each deeper than the last. The idea is to start at the first and move up according to the application's risk.
- Level 1 holds about 20% of the requirements: the minimum, first-line defences against common attacks that need no other weakness to work.
- Level 2 adds about 50% more, so meeting it means meeting around 70% of the standard. ASVS says most applications should be striving for this level. Its requirements cover less common attacks and more complex protections against common ones.
- Level 3 adds the final 30% or so: defence in depth and controls that are hard to implement, for applications that must show the highest level of security.
ASVS leaves the choice to you, based on your risks. Its own example: an early-stage startup that collects little sensitive data may start with Level 1, while a bank would struggle to justify anything below Level 3 for online banking.
One detail matters when planning a test. ASVS notes that even Level 1 is not necessarily testable from the outside alone, without access to documentation or code. That is why testers ask for test accounts, documentation and sometimes source code: the more they can see, the more of the standard they can verify.
What a web application test does not cover
ASVS is about the application. Components that handle its HTTP traffic, such as a web application firewall, a load balancer or a proxy, count where security controls depend on them, for example for rate limiting. Things that are not the application's responsibility, such as DNS, are generally out of scope, as are external processes like backups, and functional aspects, code style and policy.
The standard is frank about the limit of any scope: "There is no such thing as scope for attackers." Its advice is to look at the application alongside the rest of its life: CI/CD pipelines, hosting and operations. A web application test answers one part of that question well; it does not replace a look at the infrastructure or the people around it.
How a penetration test fits in
HackIT's web application penetration tests are done by hand, against ASVS 5.0; in a compliance audit, each finding in the report is mapped to the ASVS requirement it breaks, so it can go straight to an auditor. A good place to start is to decide which level you are aiming for and which chapters apply.
If you want to know what a test of your application would cover, talk to a tester.
Sources
- OWASP Application Security Verification Standard 5.0.0, OWASP, 30 May 2025
- ASVS/5.0/en at v5.0.0_release, OWASP, 30 May 2025
- penetration testing - Glossary | CSRC, NIST, retrieved 28 October 2026