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
Coverage typically includes authentication and session management, authorisation and access control (often the highest-impact category), input validation and injection (SQL, OS command, LDAP, XML, template injection), client-side issues (cross-site scripting, DOM manipulation), business-logic flaws specific to the application’s workflows, file upload handling, error handling and information disclosure, and the security of any third-party integrations and 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
Before major launches; after architectural changes such as introducing a new authentication provider or migrating to microservices; on a recurring annual basis at minimum; and to meet specific regulatory expectations (PCI DSS, NHS DSPT, FCA, 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.





Leave a Reply