What We Find on Web Application Penetration Tests

Web application penetration testing is one of the most requested test types and produces some of the highest-impact findings of any assessment. Customer-facing applications, internal portals, APIs, and line-of-business tools present attack surface that external network testing does not reach. Applications are complex, change frequently, and are built under delivery pressure. The findings on web application assessments reflect those realities — not negligence, but the predictable gaps that appear when security is not built into the development process from the start.

Broken access control

Broken access control is the most prevalent critical finding on web application tests. In practice, it most often manifests as insecure direct object references: a user who can access their own record at /account/1234 can access /account/1235 — another user's record — by changing the identifier in the URL or request body. The application verifies that the user is authenticated but does not verify that they are authorised to access the specific resource they are requesting.

This class of vulnerability can expose every record in an application to any authenticated user. It is easy to introduce during development, easy to miss in code review, and frequently present in applications that have had no independent security assessment. Horizontal privilege escalation — accessing other users' data at the same permission level — is the common form; vertical escalation — reaching functionality reserved for administrators — is also regularly found.

Authentication weaknesses

Authentication controls on web applications are frequently weaker in practice than organisations expect. No account lockout on login endpoints — allowing unlimited password attempts — is common. Password policies that permit short or simple passwords are regularly in place. Multi-factor authentication, where it exists, may not be enforced consistently: a common pattern is MFA on the primary login page but not on password reset flows, account recovery paths, or API endpoints that accept the same credentials.

Session management issues are found alongside these: tokens that do not expire after logout, tokens with lifetimes of days rather than hours, tokens that are transmitted over non-HTTPS connections in legacy parts of an application. Each weakness is independently exploitable; in combination they create reliable account takeover paths.

Business logic flaws

Business logic vulnerabilities are the findings that automated scanners will not surface, and they are often the highest-severity issues on an engagement. They require a tester who understands what the application is designed to do and then tests systematically whether those rules can be subverted.

Pricing manipulation in e-commerce applications — where the cost of an item is passed in a client-controlled request parameter and accepted by the server without verification against a server-side value. Workflow bypass in process-driven applications — where a required approval step can be skipped by submitting the final stage request directly. Quantity or transaction limits that can be exceeded by manipulating request parameters. Discount or voucher logic that can be applied multiple times. These vulnerabilities are unique to each application and require human understanding of the intended behaviour to find.

Injection vulnerabilities

Injection vulnerabilities — where user input is processed as code or commands rather than data — remain a consistent finding in custom-built applications. SQL injection is still found in applications built recently when development teams are not using parameterised queries throughout, or when queries are constructed dynamically in a part of the codebase where parameterisation was not enforced. A single SQL injection vulnerability in an application with access to a database of customer records is a critical finding regardless of everything else the application does well.

XML External Entity injection occurs when XML parsers are exposed to attacker- controlled input without disabling external entity processing — a feature that is off by default in many frameworks but on by default in others. Server-side template injection is found when user input is rendered through a template engine rather than treated as data. Both can lead to reading arbitrary files from the server or remote code execution.

Sensitive information disclosure

Applications regularly expose more than they should. Verbose error messages that include stack traces, database query text, or internal file paths — generated when production debug settings are enabled or exception handling is incomplete. API responses that include fields not displayed in the interface but present in the response body, including fields for other users' records. Debug and diagnostic endpoints accessible in production. Backup files or older application versions discoverable at predictable URLs. Sensitive values in JavaScript source files served to the browser.

Information disclosure findings are often reported at lower severity, but in practice they routinely provide the context needed to elevate other vulnerabilities from theoretical to directly exploitable — database structure revealed through SQL errors, internal API endpoints discovered through JavaScript, or authentication tokens found in response bodies.