Web applications are the most common attack surface for most organisations. They are publicly accessible, constantly evolving, and often handle sensitive data and business-critical functions. A web application penetration test is a thorough, manual assessment designed to find the vulnerabilities that automated scanners cannot.
Why web applications are the primary target
Every organisation with an internet presence exposes web applications to potential attackers. These applications often:
- Handle authentication and user credentials.
- Process financial transactions.
- Store and display sensitive personal data.
- Integrate with backend databases and internal systems.
- Expose APIs consumed by mobile applications and third-party services.
An attacker who compromises a web application can potentially access all of these. Web applications are also continuously updated — every new feature, integration, or code change can introduce new vulnerabilities.
The OWASP Top 10: a baseline, not a ceiling
The OWASP Top 10 is the most widely referenced list of web application security risks. It provides a useful framework for categorising common vulnerabilities, and many organisations use it as a minimum standard. But it is a baseline, not a comprehensive test plan.
A penetration tester uses the OWASP Top 10 as a starting point and then goes significantly deeper, guided by the specific application’s functionality and technology.
Injection
SQL injection, command injection, LDAP injection, template injection, and other injection flaws occur when user-supplied input is passed to an interpreter without proper validation or sanitisation. A successful injection attack can allow an attacker to read, modify, or delete data, execute commands on the server, or bypass authentication.
Testers examine every input point — form fields, URL parameters, HTTP headers, cookies, API parameters — for injection vulnerabilities. Automated scanners catch simple cases, but complex injection flaws — such as second-order SQL injection, where the payload is stored and executed later — require manual analysis.
Broken access control
Access control flaws allow users to act outside their intended permissions: viewing another user’s data, performing administrative functions without authorisation, or accessing resources that should be restricted.
This is consistently the most prevalent vulnerability category in web applications. Testers systematically test whether the application enforces authorisation at every level: can a standard user access admin endpoints? Can user A view user B’s data by modifying an ID parameter? Can an unauthenticated user access authenticated functionality?
Authentication and session management
Testers examine how the application handles authentication: password policies, account lockout, session token generation, session fixation, session timeout, MFA implementation, and password reset flows.
Common findings include predictable session tokens, sessions that do not expire, password reset links that do not invalidate after use, and MFA implementations that can be bypassed through direct API calls.
Server-side request forgery (SSRF)
SSRF vulnerabilities allow an attacker to cause the server to make requests to unintended locations — internal services, cloud metadata endpoints, or external systems. In cloud environments, SSRF can be particularly dangerous because it may provide access to instance metadata containing credentials and configuration data.
Cross-site scripting (XSS)
XSS vulnerabilities allow an attacker to inject malicious scripts that execute in other users’ browsers. While sometimes dismissed as low-impact, XSS can be chained with other vulnerabilities to steal session tokens, redirect users to phishing pages, or perform actions on behalf of the victim.
Testers test for stored XSS (the payload is saved and executed when other users view the content), reflected XSS (the payload is reflected from the URL or form input), and DOM-based XSS (the vulnerability exists in client-side JavaScript).
Beyond the OWASP Top 10
The most valuable findings in a web application penetration test are often those that no scanner would detect.
Business logic flaws
Business logic flaws are errors in the application’s intended functionality rather than technical vulnerabilities. They cannot be detected by automated scanning because they require an understanding of what the application is supposed to do.
Examples:
- A discount code that can be applied multiple times, stacking to 100%.
- A payment flow that can be interrupted after the item is dispatched but before payment is finalised.
- A role-based access control system where changing your role in a hidden form field grants administrator access.
- A registration process where manipulating the order of steps bypasses identity verification.
These flaws are specific to each application and require a tester who understands the business context to identify them.
Race conditions
Race conditions occur when the application’s behaviour depends on the timing of events. For example, if a user has a balance of 100 and submits two simultaneous transfers of 100, a race condition might allow both transfers to succeed before the balance is decremented — effectively doubling their money.
Testers use concurrency tools to submit multiple requests simultaneously and observe whether the application handles them correctly.
API-specific vulnerabilities
Modern web applications often expose APIs (REST, GraphQL, or gRPC) that serve mobile applications, single-page frontends, or third-party integrations. API testing covers:
- Authentication and authorisation on every endpoint.
- Rate limiting and abuse prevention.
- Input validation on all parameters.
- Information disclosure through verbose error messages or introspection queries (GraphQL).
- Mass assignment vulnerabilities where the API accepts more parameters than intended.
File upload vulnerabilities
If the application accepts file uploads, testers examine whether it is possible to upload files that the server will execute (web shells, server-side scripts), files that exploit processing libraries (image parsing vulnerabilities), or files that are served to other users with malicious content.
Insecure deserialization
Applications that deserialise user-supplied data (from cookies, API requests, or other inputs) may be vulnerable to attacks that manipulate the serialised data to execute arbitrary code or tamper with application state.
Why manual testing matters
Automated vulnerability scanners are useful for catching known, well-defined vulnerabilities at scale. They are fast, repeatable, and cover a broad surface area. But they have fundamental limitations:
- They cannot understand business logic.
- They cannot chain multiple lower-severity issues into a high-impact attack path.
- They generate false positives that require manual verification.
- They miss context-dependent vulnerabilities.
- They cannot test authentication flows, multi-step processes, or stateful interactions with the same depth as a human tester.
A professional web application penetration test combines automated scanning (for coverage and efficiency) with manual testing (for depth, creativity, and context). The scanner finds the obvious issues. The tester finds the ones that matter most.
What to expect from the report
A web application penetration test report includes:
- Each vulnerability documented with reproduction steps, evidence, and risk rating.
- A distinction between confirmed vulnerabilities and informational findings.
- Specific remediation guidance — not “fix the XSS” but “implement output encoding using [specific library] for all user-supplied content rendered in HTML context.”
- An assessment of the application’s overall security posture.
- Recommendations for integrating security testing into the development lifecycle.
The report should enable the development team to reproduce and fix every issue without needing to re-engage the testing team.