12 Things a Real Web Application Penetration Test Should Cover

Most web application penetration tests follow a version of the OWASP Testing Guide. That is a reasonable baseline. The problem is that "following OWASP" and "covering what matters" are not the same thing, and the gap between them is where the most impactful vulnerabilities in most applications live.

A real web application pentest is not a checklist exercise. It is an attempt to find what an attacker would actually exploit. That requires covering authentication logic, not just authentication headers. Authorization boundaries, not just access control configuration. Business workflows, not just input fields. Chained attack paths, not just individual vulnerability classes.

This post covers the twelve areas a thorough web application penetration test should cover, what each involves in practice, and what most engagements miss within each one.

1. Authentication mechanisms and session management

Authentication is the entry point for most serious web application attacks. A thorough test covers more than whether credentials are required to log in.

It should test whether password policies are enforced server-side and not just client-side, whether account lockout mechanisms can be bypassed through parameter manipulation or timing differences, and whether the login flow leaks information about valid usernames through differential responses. Multi-factor authentication flows should be tested for bypass via direct endpoint access, MFA code reuse, and race conditions in code validation.

Session management requires its own depth: whether session tokens are cryptographically random or predictable, whether they are rotated on privilege change and logout, whether logout actually invalidates tokens server-side rather than just clearing the client cookie, and whether session fixation is possible through pre-authentication token planting.

Most engagements test that authentication exists. Thorough engagements test whether it can be defeated through the full range of logic and implementation weaknesses.

2. Authorization and access control across all roles

Authorization flaws are the top vulnerability category in the OWASP Top 10 and among the most common findings in real web application engagements. Testing them properly requires more than checking whether unauthenticated users are blocked.

A complete authorization test establishes multiple user accounts at each permission level, then systematically tests whether the boundaries between them hold. Can a standard user access admin endpoints by modifying the URL? Can user A access user B's data by substituting resource identifiers? Can a read-only role trigger write operations by sending the right request directly? Can horizontal privilege escalation be achieved by manipulating user or account identifiers in API calls?

Insecure direct object references (IDOR) deserve specific, structured testing. Every endpoint that returns or modifies resources identified by sequential or guessable IDs should be tested across multiple user accounts to confirm that ownership is validated server-side rather than assumed from the authenticated session.

3. Input validation and injection vulnerabilities

Injection remains a critical vulnerability class across all web application types, and thorough testing goes well beyond checking standard SQL injection payloads against visible form fields.

SQL injection testing should cover GET and POST parameters, HTTP headers, cookie values, and any field that reaches a database query, including search functions, filter parameters, and pagination controls. Blind SQL injection, where no error or data is returned to confirm injection, requires time-based and out-of-band techniques that automated scanners often handle poorly.

Beyond SQL, a complete test covers command injection in parameters that interact with system processes, LDAP injection in directory-backed authentication, XML injection in SOAP-based services and data import functions, SSTI (server-side template injection) where user input reaches a templating engine, and NoSQL injection patterns in MongoDB and similar database queries.

4. Cross-site scripting across all output contexts

XSS testing is often treated as finding reflected inputs in form fields. Complete XSS coverage is significantly more demanding.

Reflected XSS requires testing every parameter that appears in the response, including URL parameters, HTTP header values reflected in responses, and error message content. Stored XSS requires testing every field that persists user input and is later rendered to other users, including comment fields, profile data, administrative interfaces, and data import functions. DOM-based XSS requires testing client-side JavaScript for unsafe handling of URL fragments, postMessage sources, and localStorage data.

Each XSS finding should also be assessed for exploitability: does the application's Content Security Policy prevent payload execution, are session cookies accessible to JavaScript, and is the affected endpoint reachable by users other than the submitter?

5. Business logic and workflow integrity

Business logic testing is the area where most automated tools and many manual engagements fall short. It requires understanding what the application is designed to do and then testing whether it enforces that intent.

Common business logic flaws include: manipulating prices or quantities in e-commerce flows by modifying hidden form fields or API parameters, applying discount codes multiple times by replaying or reordering requests, bypassing multi-step approval workflows by accessing the final step directly, exploiting trust relationships between application tiers where backend services assume frontend validation has already occurred, and abusing rate limits or quotas by manipulating account or session identifiers.

A tester finding these issues must understand the application's intended behavior well enough to identify where the logic can be subverted. This is the category of finding most often cited in regulatory findings and breach investigations, and the one that purely automated testing cannot systematically cover. The 10 security gaps that automated tools miss covers this in detail, including specific examples of how business logic flaws appear in production applications.

6. API security testing

Modern web applications expose their functionality through APIs more than through traditional form-based interfaces. Testing the API surface requires its own methodology.

REST API testing should cover authentication token handling, rate limiting enforcement, HTTP method manipulation (replacing GET with PUT or DELETE), mass assignment vulnerabilities where the API accepts and applies undocumented parameters, and broken function level authorization where administrative endpoints are accessible to non-administrative tokens.

GraphQL APIs require additional attention: introspection queries that expose the full schema and allow attackers to map undocumented fields, deeply nested queries that can cause denial-of-service through query complexity, batching attacks that bypass rate limits by combining many queries into a single request, and inconsistent authorization enforcement across resolver functions that expose the same underlying data through different query paths.

WebSocket connections, where present, should be tested for authentication, authorization on message types, and injection vulnerabilities in message payloads.

7. Cryptography and data protection

Cryptography failures sit at position two in the OWASP Top 10 and manifest across multiple layers of a web application.

Transport security testing covers whether TLS is enforced across all endpoints including subdomains and API endpoints, whether older protocol versions (TLS 1.0, 1.1) and weak cipher suites are accepted, and whether HTTP Strict Transport Security (HSTS) is configured to prevent downgrade attacks.

Data protection testing examines how sensitive data is handled at rest and in transit: whether passwords are stored using appropriate hashing algorithms (bcrypt, Argon2, scrypt) rather than MD5 or SHA-1, whether sensitive data appears in application logs, error messages, or browser history, and whether sensitive fields are encrypted at the database layer.

JWT implementation testing covers whether the algorithm can be manipulated to "none," whether the signing secret is weak enough to brute-force offline, whether claims are validated server-side on every request, and whether tokens remain valid after logout or account compromise.

8. File upload and file handling

File upload functionality is consistently among the highest-risk features in web applications and is frequently undertested in time-bounded engagements.

Complete file upload testing covers: whether file type validation is enforced server-side rather than relying on client-supplied Content-Type headers, whether uploaded files are stored outside the web root or with execution permissions removed, whether malicious filenames can achieve path traversal to write files to unintended locations, whether image processing libraries are vulnerable to polyglot files that execute as both valid images and server-side scripts, and whether archives (ZIP, TAR) are extracted safely without directory traversal.

File download and export functions should be tested for path traversal vulnerabilities that allow reading arbitrary files from the server filesystem, and for server-side request forgery when the application fetches content from user-supplied URLs.

9. Server-side request forgery

SSRF is consistently one of the most impactful vulnerability classes in cloud-hosted web applications because successful exploitation often leads directly to cloud credential theft via metadata service access.

SSRF testing requires identifying all parameters that the application uses to make server-side requests: URL parameters in document converters, image processors, webhook configuration, PDF generators, and any feature that fetches content from a URL. Each should be tested against internal targets including cloud metadata endpoints (169.254.169.254 for AWS, 169.254.169.254/computeMetadata/v1 for GCP), internal network ranges, and localhost services.

Blind SSRF, where the application makes the request but does not return the response to the client, requires out-of-band detection techniques and is often missed by scanners that rely on observed response differences.

10. Security headers and client-side controls

Security headers are the client-side layer that limits the impact of vulnerabilities elsewhere in the application. A complete assessment covers whether they are present, correctly configured, and not trivially bypassable.

Content Security Policy (CSP) should be assessed for whether it actually prevents XSS execution or contains common bypasses: unsafe-inline directives, overly permissive domain wildcards, JSONP endpoints on trusted domains, or Angular-based bypasses. CORS configuration should be tested for whether it reflects arbitrary Origins with credentials included, which allows cross-origin credential theft.

Additional headers to verify: X-Frame-Options or frame-ancestors CSP directive preventing clickjacking, Referrer-Policy preventing sensitive URL leakage, Permissions-Policy restricting camera, microphone, and geolocation access, and cache-control headers preventing sensitive responses from being stored in browser or proxy caches.

11. Error handling and information disclosure

Information disclosure through error messages and misconfigured responses gives attackers the intelligence needed to refine other attacks.

A thorough test covers: whether detailed stack traces, database error messages, or internal file paths appear in error responses, whether application versioning information is exposed through response headers or error pages, whether debug endpoints or administrative interfaces are accessible without authentication, whether robots.txt or sitemap files reveal sensitive endpoint paths, and whether directory listing is enabled on the web server.

Source code disclosure is particularly important: whether backup files (.bak, .old, ~), version control directories (.git, .svn), or environment configuration files (.env) are accessible from the web root.

12. Remediation validation and retesting

A penetration test that ends with a report is a penetration test that is only half finished. Confirming that identified vulnerabilities are actually resolved is a core component of a complete web application security engagement.

Remediation validation requires retesting each finding after the reported fix is deployed, confirming that the specific vulnerability is closed, and checking whether the fix introduced regressions in adjacent functionality. In time-bounded manual engagements, retesting is often scheduled as a separate engagement or deferred to the next cycle, creating a window of uncertainty between fix deployment and confirmation.

Agentic pentesting addresses this structurally. When a fix is deployed, the system retests the specific finding automatically and confirms closure the same day, producing a timestamped remediation record without requiring a separate scheduling cycle. This is one of the core operational differences between continuous agentic web application testing and periodic manual assessment, as described in the overview of how autonomous pentesting validates fixes continuously.

What most engagements miss

The twelve areas above represent the full scope of a thorough web application penetration test. In practice, most time-bounded engagements deprioritize or partially cover several of them.

Business logic testing (area 5) is the most consistently undertested: it requires application-specific understanding that takes time to develop within a fixed engagement window. GraphQL and WebSocket coverage (area 6) is frequently partial when testers apply REST-focused methodologies to modern API architectures. Blind SSRF (area 9) and DOM-based XSS (area 4) are regularly missed by automated components that rely on observed response differences.

The gap between "we ran a pentest" and "we covered the full attack surface" is where the most impactful vulnerabilities tend to live. Understanding which of the twelve areas your current or prospective engagement covers, and which it does not, is the most useful question to ask before signing an engagement contract.

For a comparison of how different testing approaches cover these twelve areas, how SAST, DAST, and agentic pentesting cover the application security stack maps each tool's coverage against the vulnerability classes above.

The 10x Pentest platform covers all twelve areas above through agentic, exploit-driven testing that runs continuously against the full application surface. For US-based organizations evaluating web application penetration testing services, review pricing for continuous coverage, or get in touch to discuss scope and methodology for your specific application.

Frequently asked questions

1. What is web application penetration testing?

Web application penetration testing is a security assessment that attempts to find and exploit vulnerabilities in a web application the way an attacker would. It goes beyond automated vulnerability scanning to include manual testing of authentication logic, authorization boundaries, business workflow integrity, and chained attack paths that automated tools cannot reason about. A thorough engagement covers the twelve areas above and produces findings with proof of exploitability rather than theoretical risk ratings.

2. How long does a web application penetration test take?

A typical manual web application penetration test takes one to two weeks for a mid-complexity application. Larger applications with extensive API surfaces, multiple user roles, and complex business logic can take two to four weeks for thorough coverage. Setup, scoping, and report writing add time before and after the active testing phase. Agentic web application pentesting compresses this timeline significantly: initial findings typically surface within hours of engagement start, with full coverage of the defined scope completed within a day.

3. How much does web application penetration testing cost?

Manual web application penetration tests typically run $8,000 to $40,000 per engagement depending on scope and vendor, with larger or more complex applications reaching higher. This cost is per engagement: quarterly testing of a single application costs $32,000 to $160,000 annually at that rate. Agentic pentesting is significantly lower cost per assessment and does not scale linearly with testing frequency, making continuous coverage of web application surfaces economically viable in a way that repeated manual engagements are not. See 10x Pentest pricing for current figures.

4. What is the OWASP Testing Guide and should my pentest follow it?

The OWASP Web Security Testing Guide (WSTG) is the most widely referenced methodology for web application security testing. It provides a structured framework covering authentication, authorization, input validation, cryptography, error handling, and other vulnerability categories. A quality web application pentest should follow the OWASP methodology as a baseline but should not be limited to it. OWASP provides the framework; the depth of coverage within each area, the business logic testing that requires application-specific knowledge, and the chained attack path discovery that connects individual findings into full exploit scenarios go beyond what the guide specifies as steps.

5. What is the difference between a web application penetration test and a vulnerability scan?

A vulnerability scan fires automated payloads at a running application and flags responses that match known vulnerability signatures. It is fast, broad, and produces output without human reasoning. A web application penetration test uses the same starting point but adds human or agentic reasoning about what findings mean, how they connect, and whether they are actually exploitable in context. Scans find surface-level issues reliably. Penetration tests find business logic flaws, authorization gaps, chained attack paths, and the vulnerability classes that require understanding how the application works before they can be identified. For a detailed comparison, what agentic AI pentesting finds that DAST misses covers the specific gaps between the two approaches.