Web Application Penetration Testing: What Gets Tested and What It Reveals

TL;DR

A web application penetration test is not an automated scan with a report attached. It is a structured, manual security assessment conducted by human testers who approach your application the way a real attacker would. The most damaging vulnerabilities in web applications, broken access control, business logic flaws, multi-step attack chains, are not found by scanners. They are found by testers who understand how the application works and look for the gaps between intended behaviour and actual behaviour.

What a web application pentest actually covers

Authentication and session management

Testing covers how the application authenticates users, how it manages sessions after authentication, and what happens at the boundaries: login, logout, password reset, account lockout, multi-factor authentication enforcement, and session token security. Authentication weaknesses are among the most commonly exploited vulnerabilities in real attacks.

Access control

Broken access control is consistently the top finding in web application security assessments. Testers verify that each user can only access the functions and data they are authorised for, that horizontal privilege escalation is not possible, that vertical privilege escalation is not possible, and that access controls are enforced server-side rather than relying on client-side restrictions.

Injection vulnerabilities

Injection testing covers SQL injection, command injection, LDAP injection, XML injection, and other injection variants across all application inputs. This includes parameters, headers, cookies, file uploads, and any other mechanism through which user-controlled data reaches the application's backend processing.

Business logic testing

Business logic flaws are the most commonly missed category in automated security testing. They arise when the application does not correctly enforce its own intended rules. Can a user manipulate a price? Can a user access another user's account by changing an ID? Can a user skip a required validation step? Can a user invoke a function they should not have access to by manipulating the request sequence? These require a tester who understands the application's purpose.

Cross-site scripting and client-side security

Testing covers cross-site scripting (XSS) across stored, reflected, and DOM-based variants, cross-site request forgery, clickjacking, content security policy configuration, and other client-side vulnerabilities that affect end users.

Application configuration and infrastructure

Misconfigurations in web servers, frameworks, and application infrastructure are a significant source of exploitable vulnerabilities. Testing covers HTTP security headers, TLS configuration, server-side configuration, error handling, and any exposed administrative interfaces or development artefacts.

What automated scanners miss

Automated vulnerability scanners are useful for coverage at scale. They are not a substitute for manual penetration testing. The gap between what a scanner finds and what a skilled human tester finds is consistently significant.

Scanners miss business logic vulnerabilities because they do not understand the application's purpose. They miss multi-step attack chains because they test inputs in isolation. They miss authentication context-dependent vulnerabilities because they cannot reason about what a logged-in user should and should not be able to do. They miss second-order injection where malicious input is stored and executed later. They generate false positives that consume remediation resources on non-issues.

A web application penetration test uses automated tools as part of the process, but the core value comes from the human tester's understanding of the application and the creativity applied to finding vulnerabilities that tools cannot detect.

Black-box, grey-box, and white-box testing

Black-box testing simulates an external attacker with no prior knowledge of the application. The tester discovers the application's functionality through exploration. This provides the most realistic simulation of an external attack but is less efficient at covering the full application surface.

Grey-box testing provides the tester with some context, typically user credentials for different roles. This allows efficient coverage of authenticated functionality and is the most common approach for web application pentests. It balances realistic attack simulation with comprehensive coverage.

White-box testing provides the tester with full technical context including source code, architecture documentation, and credentials. This allows the most thorough assessment but requires significantly more time. It is typically used for critical applications or when a comprehensive assurance review is required.

What findings look like in practice

In typical web application assessments, Sectricity testers consistently find broken object-level authorisation, where a user can access another user's data by changing an identifier in the request. They find authentication weaknesses including missing multi-factor enforcement on sensitive functions and session tokens that do not invalidate after logout. They find injection vulnerabilities in custom input handling. They find business logic flaws in multi-step processes. And they find configuration weaknesses in HTTP headers and TLS settings.

The most damaging findings are almost never the ones that scanners flag first. They are the application-specific vulnerabilities that require understanding the business context to even recognise as a problem.

FAQ

What is web application penetration testing?

Web application penetration testing is a structured security assessment of a web application conducted by human testers using the same techniques and tools that real attackers use. It covers authentication and session management, input validation, access control, business logic, client-side security, and the application's interaction with its underlying infrastructure. A web application pentest finds vulnerabilities that automated scanners miss because it requires understanding how the application works, not just what signatures it matches.

How does a web application pentest differ from a vulnerability scan?

A vulnerability scan runs automated tools against a target and reports findings based on known vulnerability signatures. It is fast and scalable but misses business logic flaws, multi-step attack chains, authentication bypasses that depend on application context, and any vulnerability that does not match a known pattern. A web application pentest involves human testers who understand how the application is supposed to work and can identify vulnerabilities that only become visible when the application is tested the way a real attacker would use it.

What does the OWASP Top 10 cover?

The OWASP Top 10 is a widely referenced list of the most critical web application security risks. It covers broken access control, cryptographic failures, injection attacks, 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. A web application pentest covers the OWASP Top 10 as a baseline but extends well beyond it to cover application-specific logic and architecture.

What is business logic testing in a web application pentest?

Business logic testing assesses whether the application enforces its intended rules correctly. Examples include: can a user purchase an item for a negative price, can a user access another user's data by changing an ID parameter, can a user skip a required step in a multi-step process, and can a user perform an action more times than the application is supposed to allow. These vulnerabilities do not appear in automated scans because they require understanding of what the application is intended to do.

How long does a web application penetration test take?

A web application penetration test typically takes between three and ten days of tester time, depending on the size and complexity of the application, the number of user roles, the complexity of the business logic, and whether the test is black-box, grey-box, or white-box. Simple applications with limited functionality can be tested in three to four days. Complex applications with many roles, integration points, and custom business logic may require eight to twelve days.

What is the difference between black-box, grey-box, and white-box testing?

Black-box testing simulates an external attacker with no prior knowledge of the application. The tester discovers the application's functionality through exploration. Grey-box testing provides the tester with some context, such as user credentials for different roles, which allows more efficient coverage of authenticated functionality. White-box testing provides the tester with source code, architecture documentation, and full technical context. Grey-box testing is the most common approach for web application pentests as it balances realistic attack simulation with efficient coverage of the full application.

Related services and resources

Sectricity conducts web application penetration testing across web applications, portals, SaaS platforms, and custom business applications. For continuous coverage, our RedSOC PTaaS platform provides on-demand testing credits across our full service catalogue. For related reading, see our guides on what a pentest is and penetration testing versus vulnerability scanning. Start with a free security scan.