OWASP Testing Methodology Deep Dive: The 12 Categories Every Web App Pentest Must Cover

Why OWASP Is the Standard

When a penetration tester says they follow a methodology, the first question should be: which one? For web application testing, the answer is almost always the OWASP Testing Guide. There are other frameworks -- PTES, NIST SP 800-115, OSSTMM -- and each has its place. But for web application security testing specifically, the OWASP Testing Guide is the most widely adopted, most comprehensive, and most frequently referenced standard in the industry.

The current version, the OWASP Web Security Testing Guide (WSTG) v4.2, organizes web application testing into 12 categories containing 91 individual test cases. Each test case includes a summary of what is being tested, the objectives, how to test for the issue, the tools that assist with testing, and references to related resources. It is, in effect, a complete checklist for web application penetration testing.

Understanding these 12 categories -- what they cover, why they matter, and how they map to real-world attacks -- helps both testers and organizations that commission tests to ensure nothing falls through the gaps. For a broader view of how OWASP fits alongside other methodologies, see our guide to penetration testing methodology and our comparison of PTES, NIST, and OSSTMM standards.

The 12 OWASP Testing Categories

1. Information Gathering (WSTG-INFO)

Information gathering is the foundation that every subsequent testing category builds on. Before testing any vulnerability, the tester must understand what the application is, how it is built, and what its exposed surface area looks like.

What is tested:

• Web server fingerprinting (server type, version, modules)
• Application framework identification (React, Angular, Django, Rails, etc.)
• Web application mapping (sitemaps, directory structures, hidden paths)
• Identification of entry points (forms, APIs, file upload endpoints)
• Review of client-side code for embedded secrets, API keys, or configuration details
• Analysis of HTTP methods supported by each endpoint

Real-world relevance: Information gathering often reveals findings before any "attack" testing begins. Exposed .git directories, debug endpoints left in production, API documentation pages that should be internal-only, and client-side JavaScript containing hardcoded credentials are all discovered during this phase. The HTTP security headers guide covers many of the configuration details assessed during information gathering.

2. Configuration and Deployment Management Testing (WSTG-CONF)

This category tests whether the application's infrastructure is configured securely. Many of the most impactful vulnerabilities are not code bugs -- they are misconfigurations in web servers, application frameworks, cloud services, and deployment pipelines.

What is tested:

• Default credentials on administrative interfaces
• Directory listing enabled on the web server
• Backup files and unreferenced files accessible via predictable paths (.bak, .old, .swp, ~)
• HTTP methods that should be disabled (PUT, DELETE, TRACE, CONNECT)
• File extension handling (can .php.jpg bypass upload restrictions?)
• HTTP Strict Transport Security, Content Security Policy, and other security headers
• Cloud storage misconfiguration (public S3 buckets, Azure blob containers)

Real-world relevance: Configuration issues are among the most frequently reported findings in penetration tests because they are so common. A web server that returns verbose error messages with stack traces, a staging environment with default admin credentials, or a cloud storage bucket with public read access are all configuration problems that require no sophisticated exploitation to abuse.

3. Identity Management Testing (WSTG-IDNT)

Identity management testing examines how the application handles user identities -- account creation, role definitions, and the relationship between identities and permissions.

What is tested:

• User registration process (can accounts be created with admin-level roles?)
• Account enumeration via registration, login, or password reset flows
• Predictable or sequential user identifiers
• Role definition gaps (are there implicit admin roles that are not properly enforced?)
• Account provisioning and de-provisioning processes

Real-world relevance: Account enumeration is a classic example. If the login page returns "invalid password" for a valid username but "user not found" for an invalid one, an attacker can compile a list of valid usernames before attempting any credential attacks. Similarly, predictable user IDs (user_1, user_2, user_3) enable attackers to enumerate and target specific accounts.

4. Authentication Testing (WSTG-ATHN)

Authentication is the gatekeeper. If authentication is broken, every other security control behind it becomes irrelevant. This category is one of the most critical in any web application test.

What is tested:

• Credential transport over encrypted channels (is the login form always served over HTTPS?)
• Default credentials on application and infrastructure components
• Account lockout mechanisms (does the application lock accounts after failed attempts? can this be used for denial of service?)
• Authentication bypass via parameter manipulation or forced browsing
• Password policy strength and enforcement
• Multi-factor authentication implementation and bypass vectors
• Session fixation during authentication
• Password reset flow vulnerabilities (predictable tokens, token reuse, lack of expiration)
• OAuth and SSO implementation weaknesses

Real-world relevance: Authentication vulnerabilities consistently rank among the most severe findings. A password reset flow that generates predictable tokens, an MFA implementation that can be bypassed by removing a parameter from the request, or a session that is not regenerated after authentication all represent direct paths to account takeover.

# Example: Testing for authentication bypass via parameter manipulation
# Original authenticated request
POST /api/user/profile HTTP/1.1
Cookie: session=abc123

# Test: Can the endpoint be accessed without authentication?
POST /api/user/profile HTTP/1.1

# Test: Does removing the session cookie return the same data?
# Test: Does substituting another user's session return their data?

5. Authorization Testing (WSTG-ATHZ)

Authorization testing determines whether the application correctly enforces who can access what. Authentication confirms identity; authorization enforces permissions. They are distinct controls, and both must be tested independently.

What is tested:

• Path traversal (can users access files outside the intended directory?)
• Privilege escalation (can a regular user access admin functions?)
• Insecure direct object references (IDOR -- can user A access user B's resources by changing an identifier?)
• Horizontal access control (same role, different user's data)
• Vertical access control (different role, higher privilege functions)
• Access control based on HTTP method (does changing GET to POST bypass a restriction?)
• API endpoint authorization (are all endpoints consistently enforcing the same authorization model?)

Real-world relevance: IDOR vulnerabilities are among the most common and most impactful findings in modern web application tests. A URL like /api/invoices/12345 that returns any invoice when the ID is changed, regardless of which user is authenticated, is a textbook IDOR. These vulnerabilities are invisible to automated scanners because the scanner does not understand the application's authorization model -- it cannot distinguish between data the user should see and data they should not.

6. Session Management Testing (WSTG-SESS)

Sessions are the mechanism that maintains state between an authenticated user and the application. Weak session management can allow an attacker to hijack a legitimate user's session without ever compromising their credentials.

What is tested:

• Session token randomness and predictability
• Session fixation (can an attacker set a victim's session ID before they authenticate?)
• Session token exposure in URLs, logs, or referrer headers
• Session timeout and expiration enforcement
• Cross-site request forgery (CSRF) protection
• Cookie security attributes (Secure, HttpOnly, SameSite, Path, Domain)
• Concurrent session handling (does logging in on a new device invalidate existing sessions?)

Real-world relevance: Session tokens in URL parameters are still surprisingly common. When a session token appears in the URL, it gets logged by web servers, cached by proxies, stored in browser history, and leaked via the Referer header when the user clicks any external link. A single leaked session token means complete account takeover.

7. Input Validation Testing (WSTG-INPV)

Input validation testing covers the broadest and most technically diverse category in the OWASP Testing Guide. This is where the classic web application attack classes live.

What is tested:

• SQL injection (classic, blind, time-based, second-order)
• Cross-site scripting (reflected, stored, DOM-based)
• Command injection (OS command execution via user input)
• LDAP injection, XML injection, XPath injection
• Server-side template injection (SSTI)
• Server-side request forgery (SSRF)
• HTTP header injection and response splitting
• File inclusion (local and remote)
• Format string vulnerabilities
• Buffer overflow (less common in modern web apps, but still relevant for certain technology stacks)

Real-world relevance: SQL injection and XSS remain in the OWASP Top 10 because they are still found in production applications. Modern frameworks mitigate many basic forms of these attacks, but edge cases persist: raw SQL queries in admin search functions, user input reflected in error messages without encoding, template injection in email rendering engines, and SSRF vulnerabilities in URL preview or webhook features.

# Example: Testing for SQL injection in a search parameter
# Normal request
GET /api/products?search=laptop HTTP/1.1

# SQL injection test payloads
GET /api/products?search=laptop' OR '1'='1 HTTP/1.1
GET /api/products?search=laptop' UNION SELECT null,null,null-- HTTP/1.1
GET /api/products?search=laptop'; WAITFOR DELAY '0:0:5'-- HTTP/1.1

8. Error Handling Testing (WSTG-ERRH)

How an application handles errors reveals information about its internal structure, technology stack, and potential weaknesses. Error handling is a small category but an important one.

What is tested:

• Verbose error messages that reveal stack traces, database queries, or file paths
• Different error responses for different error conditions (enabling enumeration)
• Custom error pages vs. default framework error pages
• Error handling in API responses (do API errors expose internal implementation details?)
• Unhandled exception behavior

Real-world relevance: A stack trace in a production error message can reveal the application framework and version, database type, internal file paths, library versions, and sometimes even fragments of source code. This information directly assists an attacker in selecting targeted exploits. The fix is straightforward -- custom error pages in production, detailed logging server-side only -- but it is frequently overlooked.

9. Cryptography Testing (WSTG-CRYP)

Cryptography testing examines how the application uses encryption, hashing, and random number generation. Weak cryptographic implementations can undermine the security of authentication, data protection, and transport security.

What is tested:

• TLS protocol versions and cipher suite configuration
• Certificate validity, chain completeness, and algorithm strength
• Padding oracle vulnerabilities
• Weak encryption algorithms in application-level crypto (MD5, SHA1 for password hashing, DES/3DES for encryption)
• Insecure random number generation (predictable tokens, session IDs, or nonce values)
• Sensitive data stored or transmitted without encryption

Real-world relevance: TLS misconfiguration is one of the most commonly reported findings. Support for deprecated protocol versions (TLS 1.0, TLS 1.1), weak cipher suites, or missing HSTS headers are all cryptographic issues that affect the application's transport security. At the application level, password hashing with MD5 or SHA1, JWT tokens signed with weak keys, and predictable password reset tokens are frequently encountered. For a comprehensive treatment of TLS assessment, see our guide to TLS auditing beyond the padlock.

10. Business Logic Testing (WSTG-BUSL)

Business logic testing is the category that separates a real penetration test from an automated scan. Scanners cannot understand business rules, workflow sequences, or the intended behavior of application features. Business logic flaws require a human tester who understands both the application's purpose and an attacker's mindset.

What is tested:

• Workflow bypass (can steps in a multi-step process be skipped or reordered?)
• Integrity checks (can pricing, quantities, or discount codes be manipulated client-side?)
• Upload validation bypass (does server-side validation match client-side restrictions?)
• Race conditions (can concurrent requests exploit timing windows?)
• Feature misuse (can legitimate features be abused for unintended purposes?)
• Circumvention of limits (transaction limits, rate limits, account limits)

Real-world relevance: Business logic flaws are often the most severe findings in a penetration test because they represent direct business impact. A checkout flow that allows negative quantities (resulting in credits), a referral system that can be exploited with self-referrals, a file upload that restricts client-side but not server-side, or a rate limit that resets when a request parameter changes -- these are all business logic issues that no scanner will find and that have direct financial or operational impact.

# Example: Testing checkout flow business logic
# Normal checkout
POST /api/checkout HTTP/1.1
{"items": [{"id": "PROD-1", "quantity": 2, "price": 49.99}]}

# Business logic test: Can the price be modified client-side?
POST /api/checkout HTTP/1.1
{"items": [{"id": "PROD-1", "quantity": 2, "price": 0.01}]}

# Business logic test: Negative quantity
POST /api/checkout HTTP/1.1
{"items": [{"id": "PROD-1", "quantity": -1, "price": 49.99}]}

11. Client-Side Testing (WSTG-CLNT)

Client-side testing focuses on vulnerabilities that execute in the user's browser rather than on the server. With the prevalence of single-page applications and heavy client-side logic, this category has grown significantly in importance.

What is tested:

• DOM-based cross-site scripting (XSS that never touches the server)
• JavaScript execution via URL fragments, postMessage, or DOM manipulation
• Client-side storage security (localStorage, sessionStorage, IndexedDB containing sensitive data)
• Clickjacking (can the application be framed and overlaid with deceptive content?)
• Cross-origin resource sharing (CORS) misconfiguration
• WebSocket security
• HTML5 feature abuse (service workers, Web Storage API, geolocation)
• Tabnabbing via target="_blank" without rel="noopener"

Real-world relevance: CORS misconfiguration is a particularly impactful client-side finding. An API that responds to requests from any origin with Access-Control-Allow-Origin: * while also allowing credentials effectively disables the same-origin policy for that endpoint. An attacker's website can make authenticated requests to the API and read the responses, enabling complete data exfiltration through the victim's browser.

12. API Testing (WSTG-APIT)

The newest category in the OWASP Testing Guide reflects the reality that APIs are now the primary interface for most modern applications. Mobile apps, single-page applications, and third-party integrations all communicate through APIs, making them the largest and most critical attack surface.

What is tested:

• GraphQL-specific vulnerabilities (introspection disclosure, query depth attacks, batch query abuse)
• REST API endpoint enumeration and documentation exposure
• API rate limiting and resource consumption
• Mass assignment vulnerabilities (can users set fields they should not have access to?)
• JWT validation and token handling
• API versioning and deprecated endpoint exposure
• Webhook security (can webhook endpoints be abused or forged?)

Real-world relevance: API vulnerabilities are responsible for a growing share of data breaches. The OWASP API Security Top 10 (2023 edition) highlights broken object-level authorization, broken authentication, and unrestricted resource consumption as the top risks. Many organizations secure their web application frontend but leave the underlying API endpoints with weaker controls, assuming the frontend enforces the rules. An attacker who calls the API directly bypasses those frontend controls entirely. For a deeper treatment of API security assessment, see our guide on API security beyond status codes.

Applying OWASP in Practice

Coverage vs. Depth

The 91 test cases in the OWASP Testing Guide represent comprehensive coverage. In a real engagement, the tester must balance coverage against depth. A two-week web application test cannot exhaustively test every one of the 91 cases to maximum depth on a complex application. The tester's judgment -- informed by the information gathering phase, the application's technology stack, and the intelligence from automated reconnaissance -- determines where to go deep and where broad coverage is sufficient.

Business logic testing, authentication, and authorization typically receive the most attention because they produce the highest-impact findings and are the areas where automated tools provide the least value. Configuration and error handling testing, by contrast, can be partially automated and verified quickly.

Mapping OWASP to Compliance Requirements

Many compliance frameworks reference OWASP specifically:

• PCI DSS 4.0 Requirement 6.2 maps required testing categories directly to OWASP Top 10 vulnerability classes
• SOC 2 auditors commonly accept OWASP-aligned test reports as evidence for the security monitoring criteria
• HIPAA security assessments benefit from OWASP's structured approach to demonstrating thorough testing
• DORA threat-led penetration testing can use OWASP as the web application testing component within the broader TLPT framework

When your penetration test follows OWASP methodology and the report explicitly maps findings to OWASP test case identifiers (e.g., WSTG-ATHN-02 for default credential testing), auditors can trace each test directly to the methodology. This traceability significantly reduces audit friction.

Common Gaps in OWASP Coverage

While the OWASP Testing Guide is comprehensive for web applications, it does not cover everything a modern engagement might require:

• Mobile application testing requires the OWASP Mobile Application Security Testing Guide (MASTG) as a companion
• Cloud infrastructure testing is outside OWASP's scope and requires cloud-specific methodologies
• Network-layer testing is covered by PTES and NIST SP 800-115 rather than OWASP
• Social engineering is not addressed by OWASP

A complete penetration testing program often combines OWASP for web application testing with PTES or NIST for network and infrastructure testing. Our article on PTES and NIST penetration testing standards covers how these frameworks complement OWASP.

Evaluating Whether Your Pentest Follows OWASP

When reviewing a penetration test proposal or report, look for these indicators that the tester follows OWASP methodology:

• Explicit methodology reference. The report should cite the OWASP Web Security Testing Guide by name and version.
• Category coverage. The report should address all 12 testing categories, even if some are noted as out of scope with justification.
• Test case identifiers. Individual findings should reference the specific OWASP test case they relate to (e.g., WSTG-INPV-01 for SQL injection).
• Structured evidence. Each finding should include reproduction steps, not just a severity rating from an automated tool.

If your penetration test report reads like automated scanner output with CVSS scores but no methodology references, exploitation narratives, or business logic testing, it was not conducted following OWASP methodology regardless of what the proposal claimed.

Next Steps

Understanding the OWASP Testing Guide helps you evaluate the quality of penetration testing proposals and reports, ensuring your investment delivers comprehensive coverage rather than surface-level scanning.

If you are ready to commission a web application penetration test that follows OWASP methodology, our penetration testing scoping wizard captures the application details needed to scope an engagement properly. For organizations that want continuous visibility into the findings from OWASP categories 1 through 3 and 9 (information gathering, configuration, identity management, and cryptography), our CyberShield platform provides automated, ongoing assessment of these areas between manual tests.