Web Application Penetration Testing: Complete Guide

A web pentest (or web application penetration test) is a manual and authorised attack against a web application to find exploitable security flaws before a real attacker does. It goes far beyond running a scanner: the team combines automation with human judgement, chains vulnerabilities together, abuses business logic, and delivers a report with reproducible proof of concept and justified CVSS severity. In the European market it is the technical test that evidences mandatory controls under NIS2, DORA, ENS, ISO 27001 and PCI DSS on any internet-facing application.

This guide covers what a web pentest actually is, the phases, the most exploited vulnerabilities in 2025-2026, the difference with SAST, DAST and WAF, and how to choose a provider that adds real value to the development cycle.

What a web pentest is

A web pentest is an authorised and scoped offensive exercise against one or several of the organisation's HTTP/HTTPS applications: corporate portals, admin panels, e-commerce, SaaS platforms, REST and GraphQL APIs, internal applications. The goal is not to count theoretical vulnerabilities, it is to demonstrate which real flaws the application has, how they get exploited and what impact they would have in the hands of a motivated attacker.

Unlike an automated web scanner (Nuclei, Acunetix, Burp Scanner, ZAP), a professional web pentest:

• Chains vulnerabilities that individually look minor. An information leak exposing internal emails, an IDOR allowing visibility of other users' profiles and an SSRF reaching cloud metadata can combine into full control of the production environment. Real exploits are almost always chains, not a single critical bug.
• Audits business logic, not just technical patterns. A scanner detects SQL injection; a pentester detects that applying the "ADMIN10" coupon three times gives the product for free, or that changing the user role in a hidden JSON body grants administrator privileges.
• Delivers reproducible proof of concept: request and response captures, minimum viable scripts, video of the attack when needed. Without that, the development team has nothing to fix from.
• Justifies CVSS severity against business impact, not against a generic table.

Typical duration of a web pentest runs from 5 to 15 working days depending on the size of the application, its surface and the agreed methodology.

Why do a web pentest: real business value

Web applications are the most common entry vector in incidents affecting European companies according to annual ENISA and INCIBE reports. Three numbers any CISO already knows:

• More than 70% of breaches with exfiltrated data start in a misconfigured or unpatched web application.
• The average remediation cost after an incident with personal data triples the cost of a full annual pentest.
• The average time between an attacker exploiting a web vulnerability and reaching internal persistence is under 24 hours in organisations without a SOC.

Done well, a web pentest delivers five concrete results:

1. Prioritised inventory of real flaws with justified severity, not long lists without context.
2. Reproducible evidence so development can fix without guessing.
3. Demonstrable regulatory compliance for NIS2, ENS, ISO 27001 or PCI DSS audits.
4. Honest reading of the state you can present to the board or a B2B client during due diligence.
5. Measurable risk reduction after correcting and passing the retest.

Web pentest vs SAST, DAST and WAF: how they fit

In any application security (AppSec) programme four layers coexist. Confusing them leads to buying what you don't need:

• SAST (Static Application Security Testing). Static analysis of source code. Detects insecure patterns in the code before compilation. Used by the development team during continuous integration (CI).
• DAST (Dynamic Application Security Testing). Automatic dynamic analysis on the running application. Fires payloads against the exposed application and looks at the responses. What Acunetix, ZAP, Burp Scanner and similar do. Detects the automatable.
• Web pentest. Manual analysis with tools. Chains vulnerabilities, abuses business logic, validates real exploitability. What DAST does not detect.
• WAF (Web Application Firewall). Defensive layer in front of the application that blocks known attacks. It doesn't fix vulnerabilities, it mitigates them temporarily.

Quick rule: SAST and DAST integrate in CI/CD to catch the cheap and fast. Web pentest is contracted periodically to find what automation misses. WAF protects the perimeter while findings get fixed. The four layers are complementary, not alternatives.

Types of web application and how the pentest changes

A "web pentest" changes with the nature of the application:

• E-commerce and marketplace. Focus on order management, coupons, cart, payment gateway, returns, reviews. Business logic vulnerabilities (negative price, unlimited discounts, IDOR over other users' orders) are usually the most impactful.
• Multi-tenant SaaS. Focus on isolation between tenants, object-level authorisation, JWT tokens, role management, admin panel. Bad authorisation breaks the fundamental promise of the product.
• Internal admin panel. Focus on authentication, MFA, VPN access, information leaks in responses, ability to escalate privileges.
• REST APIs, GraphQL, gRPC. Focus on per-endpoint authentication, object-level and function-level authorisation, rate limiting, mass assignment, data exposure. The OWASP API Security Top 10 is the standard.
• Single Page Application (SPA) with backend. The boundary between client and server matters: any critical validation that lives only in JavaScript is bypassable.
• Legacy applications with several years in production. Focus on outdated components, inherited leaks, old configurations, security technical debt.

A modern mid-sized application usually needs one full web pentest piece a year and a retest after every significant change in authentication, authorisation or payments.

OWASP WSTG and OWASP Top 10: the industry standards

The two standards any professional provider follows are:

• OWASP Web Security Testing Guide (WSTG). The detailed step-by-step methodology, with more than 90 controls across 12 categories: information gathering, server configuration, identity management, authentication, authorisation, session management, input validation, error handling, cryptography, business logic, client-side and APIs. The reference manual that structures the pentest.
• OWASP Top 10. The list of the 10 most critical vulnerability categories in web applications. The 2021 edition (current with 2025 update) includes Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures, and Server-Side Request Forgery. There's a detailed analysis of each category in OWASP Top 10 2025: business vulnerabilities.

A professional provider explicitly declares it follows OWASP WSTG and delivers findings mapped to OWASP Top 10 + CWE + CVSS so they are comparable and auditable.

The technical phases of a professional web pentest

A competent web pentest always follows the same six phases:

1. Pre-engagement and scoping

Written definition of what gets attacked and what doesn't: domains, subdomains, excluded endpoints, time windows, permitted techniques (denial of service: rarely), test credentials for each role, agreements on sensitive data. Without this phase signed, you don't start.

2. Reconnaissance

Mapping of the application's real surface: subdomains, hidden endpoints, parameters, technologies, versions, error behaviour, certificates, leaks in public repositories. Typical tools: subfinder, ffuf, httpx, gau, waybackurls, GitHub dorks.

3. Application analysis

Manual walkthrough with the credentials of each role, identification of sensitive endpoints, mapping of the authentication, authorisation and session flows. Attack hypotheses get built here.

4. Exploitation

Active testing guided by OWASP WSTG: SQL injection, XSS, IDOR, SSRF, insecure deserialisation, JWT token abuse, path traversal, open redirect, race conditions, mass assignment, exposure of sensitive information in responses, business logic abuse. Every finding gets documented with request, response and impact.

5. Post-exploitation and chaining

Combination of findings to escalate impact: a leak + an IDOR + an SSRF can turn into takeover of the cloud account behind the application. Without this phase, the report minimises real risk.

6. Documentation and report

Final deliverable with executive summary, detailed findings (CVSS v3.1 severity, description, proof of concept, impact, recommendation), annexes with exploitation chains and a mapping table to OWASP Top 10 + CWE. Weeks later, optional retest to validate that the applied corrections work.

Most exploited web vulnerabilities in 2025-2026

Regardless of sector or application size, the most frequent and highest-impact findings we see in web pentests are:

• Broken Access Control. IDOR, horizontal and vertical privilege escalation, admin endpoints reachable from the user role. Still the category with the highest average impact.
• SQL and NoSQL injection in parameters that didn't look critical (filters, searches, CSV exports).
• Server-Side Request Forgery (SSRF) in functions that download images, generate PDFs, import URLs or load webhooks. Frequently combinable with cloud metadata (IMDS) to take temporary credentials.
• Cross-Site Scripting (XSS) persistent in CMS and reflected in search parameters. Exploitation with modern frameworks needs more creativity but the vulnerability is still present.
• Vulnerabilities in outdated components (frontend libraries, session managers, backend frameworks with public CVEs unpatched). More in what is a CVE.
• Bad header and CORS configuration that allows bypassing browser protections.
• Poorly validated JWT tokens (algorithm none, signature not verified, modifiable claims) that break the authentication model. More in JWT security: vulnerabilities and best practices.
• Broken business logic: negative price, negative quantity, reusable coupons, race conditions in transactions.

For each category in depth, see OWASP Top 10 2025: business vulnerabilities.

White-box, black-box and grey-box in web pentest

The information model handed to the team changes the result:

• Black-box. Public URL only. The pentester acts as an external attacker without context. Useful to measure real exposure, inefficient to find deep flaws.
• Grey-box. URL plus credentials for every relevant role (user, admin, external tenant). The most common model in web pentest because it balances realism with efficiency.
• White-box. URL, credentials for every role, source code and architecture. For maximum technical coverage in critical applications.

For a more detailed explanation, see white-box vs black-box vs grey-box testing.

Web pentest and compliance

Web applications are one of the priority assets for almost every framework:

• NIS2 (article 21.2). Periodic technical tests as a mandatory risk management measure. Exposed applications are always priority scope. More in NIS2 in Spain: a compliance guide for 2026.
• DORA (EU Regulation 2022/2554). Advanced testing and, for designated entities, TLPT accredited under TIBER-EU. More in DORA compliance guide for financial entities 2026.
• ENS (Spanish Royal Decree 311/2022). Mandatory penetration testing in medium and high categories, annual.
• ISO 27001 (control A.8.29). Technical security testing on information systems.
• PCI DSS v4.0 (req. 11.4). Pentesting of applications processing card data, annual and after significant changes.

A well-designed web pentest covers technical evidence for several frameworks at the same time. That's what a professional provider should articulate in the proposal.

How to choose a web pentest provider

Four criteria separate a provider that adds real value from one that delivers a Burp Scanner report painted blue:

1. Team with demonstrable experience in modern web applications. Ask for names, certifications (OSWE, eWPTX, BSCP, GWAPT) and references for similar applications in sector and stack. A serious team answers without hesitation.

2. Own research and published CVEs. Providers who discover vulnerabilities in commercial software demonstrate real technical capacity. On the Secra research page we list the CVEs discovered by our team (CVE-2025-40652 in CoverManager and CVE-2023-3512 in Setelsa ConacWin CB).

3. Explicit methodology based on OWASP WSTG. The proposal must declare which WSTG controls it covers and how. If the document doesn't say it, there probably is no real methodology.

4. Sample report quality. Ask for an anonymised sample report. Look at whether findings are prioritised, whether the proof of concept is reproducible, whether CVSS severity is justified and whether the executive section speaks in business terms.

What shouldn't be a criterion: the lowest price. A low-cost web pentest almost always means an automated scanner with a generic template. The difference shows up when an incident hits. More on pricing in penetration testing pricing in Spain.

When and how often to run a web pentest

Four situations that trigger a web pentest:

1. Before going to production a new application or a major change in authentication, authorisation or payments.
2. Annually at minimum to keep compliance evidence.
3. After an incident or near miss to validate the root cause has been closed.
4. Under contractual demand during due diligence or renewal with a B2B client.

Quick heuristic: if your organisation publishes a web application externally, once a year is the floor. If the application handles regulated data (health, financial, critical infrastructure), twice a year is more realistic.

Frequently asked questions

How long does a web pentest take?

Between 5 and 15 working days of active execution depending on application size, number of roles and agreed methodology. The report typically arrives 3 to 7 days after the technical phase closes. The retest (optional but recommended) runs a few weeks later, once corrections have been applied.

What's the difference between a web pentest and a web audit?

In practice the two terms are often used as synonyms when referring to an offensive test with scoped reach on an application. The precision: "audit" can include documentary and compliance review; "pentest" focuses on the technical exploitative test. If you contract, make sure the proposal declares methodology (OWASP WSTG) and delivers a report with proof of concept.

Does an automated scanner replace a web pentest?

No. A scanner detects known vulnerabilities at first sight but does not chain findings, does not abuse business logic and does not validate real exploitability. Useful as a continuous layer inside CI/CD, but does not replace the manual pentest a professional provider runs once a year.

What credentials and access does the pentester need?

In grey-box (the most common), test credentials are provided for every relevant role: standard user, premium user, admin, external tenant, unverified account. These accounts usually point to non-production data. The ROE detail how sensitive data appearing during the test is handled, kept and destroyed.

Can a web pentest break the application?

A professional pentest minimises operational risk: written ROE, agreed time windows, potentially disruptive techniques excluded or run in pre-production and emergency contacts available. The real risk is not zero, but it is far below the risk of discovering the flaw when a real attacker exploits it.

How does the web pentest fit with the WAF?

They complement each other. The WAF blocks known attacks and reduces noise in the logs, but does not fix vulnerabilities. The web pentest finds the flaws so they get fixed in the code. Having a WAF without having run a pentest is defending a door knowing the burglar can come through an open window you never checked.

Does the web pentest cover APIs?

Depends on the agreed scope. The usual practice in a modern application is to contract web pentest and API pentest together, because frontend and backend form a single system from the attacker's view. If your application is mainly API (mobile + API, B2B integrations), a specific API pentest following OWASP API Security Top 10 makes more sense. More in API penetration testing: REST and GraphQL.

Which certifications should the web pentest team hold?

The most recognised in web applications are OSWE (Offensive Security Web Expert), eWPTX (eLearnSecurity Web Application Penetration Tester eXtreme), BSCP (Burp Suite Certified Practitioner) and GWAPT (SANS / GIAC Web Application Penetration Tester). A certification alone does not guarantee quality, but its total absence in the team assigned to the project is a red flag.

How we run web pentests at Secra

At Secra we run web pentests against OWASP WSTG with a team that publishes its own research, delivers reports with reproducible proof of concept, justified CVSS severity and an executive summary separated from the technical detail. The scope is designed so the same test serves as evidence for NIS2, DORA, ENS, ISO 27001 or PCI DSS audits as applicable. When the application has an associated API or mobile app, the scope can be widened to cover the whole system in a single project.

If you want a concrete proposal for your application, get in touch through contact or check the web and mobile audit service. If you're looking for a broader view of pentesting that includes infrastructure and cloud beyond applications, the prior reading is what is a penetration test.