Cyber Security: What is web application penetration testing?

Web application penetration testing is a security assessment of a website, web service, or API that aims to find and demonstrate flaws an attacker could exploit. The target may be a public-facing marketing site, a customer portal, an internal administrative application, a single-page React or Vue application backed by APIs, or a pure machine-to-machine API.

What gets tested

A web application penetration test covers authentication, session management, authorisation, input validation, client-side issues, business-logic flaws, file uploads, error handling and third-party integrations. Access control testing often delivers the highest-impact findings, alongside the classic injection and cross-site scripting checks.

Injection testing spans SQL, OS command, LDAP, XML and template injection, while client-side coverage includes DOM manipulation alongside cross-site scripting. Business-logic testing targets flaws specific to the application’s workflows, and the assessment also examines information disclosure and the security of supply-chain components.

Methodology

The dominant frameworks are the OWASP Application Security Verification Standard (ASVS) and the OWASP Web Security Testing Guide (WSTG). Most engagements also align with the Penetration Testing Execution Standard (PTES) and, where CREST membership is required, with CREST’s own methodology. The work is typically grey-box: the tester receives credentials at multiple privilege levels and high-level architecture so they can spend time on deeper issues rather than reconnaissance.

Common tools

Burp Suite Professional is the standard manual-testing platform. Supporting tools include OWASP ZAP for free alternatives, sqlmap for automating SQL injection, Postman or curl for crafting API requests, and Wireshark for low-level traffic inspection. Automated scanners (Burp Scanner, Acunetix, Netsparker) provide breadth on known-pattern issues but cannot replace manual testing for business-logic flaws.

Common findings

Broken access control where the application trusts a client-supplied identifier; missing authorisation on individual API endpoints; insecure direct object references; vertical privilege escalation; weak password and session policies; missing rate limits on authentication endpoints; second-order SQL injection; reflected and stored cross-site scripting on lightly-protected pages; CSRF on state-changing endpoints; verbose error messages exposing stack traces or internal paths; misconfigured CORS allowing untrusted origins.

When to test

Test before major launches, after architectural changes, on a recurring annual basis at minimum, and whenever a regulator or standard expects it. Significant shifts such as introducing a new authentication provider or migrating to microservices change the attack surface enough to justify a fresh assessment rather than waiting for the next scheduled test.

Regulatory drivers include PCI DSS, NHS DSPT, FCA expectations, and the ICO under UK GDPR Article 32. For agile teams, lighter “delta” assessments between major tests provide ongoing coverage without the cost of a full re-test.

Related terms

See also: penetration testing, Burp Suite, SQL injection, and cross-site scripting.