OWASP Testing Guide: Security Testing Categories, Tools, and How to Start

An OWASP scanner follows the methodology defined in the OWASP Testing Guide — a comprehensive framework for finding security flaws in web applications. The guide breaks security testing into structured categories so you can systematically verify that your application handles authentication, input validation, session management, and other attack surfaces correctly. Instead of guessing what to test, you follow a repeatable process grounded in decades of community research.

The OWASP Testing Guide is a methodology, not a tool. No single scanner covers every testing category. You need a combination of SAST, DAST, and manual review to achieve full coverage across all OWASP-defined test cases.

Scan your code against OWASP categories with Rafter →

What the OWASP Testing Guide Covers

The OWASP Testing Guide (currently v4.2) defines what to test, how to test it, and what results to expect — organized into phases that map to a typical development lifecycle. It starts with information gathering and moves through progressively deeper testing, with each test case including vulnerability descriptions, step-by-step procedures, and remediation guidance.

The guide contains over 90 individual test cases grouped into 11 categories. Each test case follows a consistent structure: a summary of the vulnerability, the objectives of the test, how to execute it (with both automated and manual approaches), and what to do when you find the issue. This structure makes it usable as a living checklist — you can assign test cases to team members, track completion, and measure coverage over time.

Unlike the OWASP Top 10, which ranks risks by prevalence, the Testing Guide is a methodology. It tells you how to verify whether a vulnerability exists in your specific application, not just that the vulnerability class is common in the wild.

OWASP Top 10 as a Testing Baseline

The OWASP Top 10 is the minimum set of risks your testing should cover. Every category in the Top 10 — injection, broken authentication, security misconfiguration, and others — maps directly to specific test cases in the Testing Guide.

If you are starting from zero, use the Top 10 as your initial checklist. It covers the vulnerabilities that appear most frequently in real-world applications. As your security practice matures, expand into the full Testing Guide for deeper coverage.

The mapping is not one-to-one. A single Top 10 category like "A03:2021 Injection" maps to dozens of individual test cases across Input Validation, including SQL injection, LDAP injection, XML injection, command injection, and template injection. The Testing Guide gives you the procedures to verify each of those individually, while the Top 10 gives you the priority order.

Testing Categories in Detail

The Testing Guide organizes security tests into 11 categories that cover distinct attack surfaces. Understanding what each category targets helps you assign the right tools and allocate time proportionally during a security review.

Information Gathering

Information gathering is the reconnaissance phase. You identify technologies in use (web server, framework, languages), map the application's endpoints and URL structure, enumerate subdomains, and discover hidden resources like admin panels, backup files, and API documentation that was never meant to be public.

Practical tests include fingerprinting the web server through HTTP response headers, analyzing robots.txt and sitemap.xml for paths the application tries to hide from search engines, and reviewing JavaScript source files for hardcoded API keys or internal endpoint references. Automated tools like httpx and nuclei handle bulk fingerprinting, but manual review of client-side source often reveals endpoints that crawlers miss.

Configuration and Deployment Management

This category tests whether your infrastructure is hardened. Default credentials on admin interfaces, unnecessary HTTP methods like PUT or DELETE enabled on the server, directory listings exposing file structures, verbose error pages in production, and misconfigured CORS policies all fall here.

You should verify that TLS configurations follow current best practices — no SSLv3, no weak cipher suites, HSTS headers present with adequate max-age. Test that your deployment strips development-only headers, disables debug endpoints, and locks down cloud storage buckets. A surprising number of breaches trace back to an S3 bucket with public-read permissions or an exposed .env file in the web root.

Identity Management

Identity management testing examines how your application provisions, manages, and deactivates user accounts. You test whether user registration is protected against automated bulk account creation, whether usernames or email addresses are enumerable through registration or password reset flows, and whether role definitions follow least-privilege principles.

A common failure here is account enumeration through differential responses. If your login page returns "invalid username" versus "invalid password" as distinct error messages, an attacker can confirm which accounts exist before attempting credential stuffing. The fix is a generic "invalid credentials" message regardless of which field is wrong.

Authentication Testing

Authentication testing goes deeper than identity management by attacking the login mechanism itself. You test for brute-force resistance (account lockout or rate limiting after failed attempts), credential stuffing defenses, default or weak password policy enforcement, and bypass vulnerabilities in multi-factor authentication flows.

Key test cases include verifying that password reset tokens are single-use and time-limited, that authentication state cannot be manipulated through client-side cookie tampering, and that OAuth or SAML flows validate redirect URIs to prevent authorization code interception. If your application uses JWT for authentication, test that it validates the alg header and rejects none algorithm tokens.

Authorization Testing

Authorization testing verifies that users can only access resources they own or have been explicitly granted permission to view. This is where you check for Insecure Direct Object Reference (IDOR) vulnerabilities — can user A access user B's data by changing an ID in the URL? Can a regular user access admin endpoints by guessing the path?

Test both horizontal privilege escalation (accessing another user's data at the same role level) and vertical privilege escalation (performing actions reserved for a higher role). Automated DAST tools struggle with authorization testing because they lack context about what each user should be allowed to do. This is where SAST tools that understand your authorization middleware add significant value.

Session Management

Session management testing checks that session tokens are generated securely, expire correctly, and resist fixation and hijacking attacks. You verify that tokens have sufficient entropy (at least 128 bits of randomness), that the server invalidates sessions on logout, and that session cookies carry the Secure, HttpOnly, and SameSite attributes.

Test for session fixation by checking whether the application issues a new session token after successful login. If the pre-authentication token persists post-login, an attacker who sets a known token in the victim's browser before login can hijack the session afterward. Also verify that concurrent session limits exist where appropriate — if a user logs in from a new device, consider whether the old session should be invalidated.

Input Validation

Input validation is the largest testing category and covers every injection class. You test every user-controlled input — form fields, URL parameters, HTTP headers, cookies, file uploads, and API request bodies — for SQL injection, cross-site scripting (XSS), command injection, path traversal, Server-Side Request Forgery (SSRF), XML External Entity (XXE) injection, and template injection.

For each injection type, the Testing Guide specifies both automated scanning approaches and manual payloads. SQL injection testing, for example, includes time-based blind injection techniques where the payload forces a database delay rather than returning visible output. XSS testing covers reflected, stored, and DOM-based variants, each requiring different detection approaches.

SAST tools are particularly effective here because they trace tainted data from its entry point through every code path to a security-sensitive sink — a database query, a system command, an HTML template render. This catches injection paths that DAST tools miss because the vulnerable code path requires a specific sequence of requests or a particular application state.

Error Handling

Error handling testing confirms that error messages do not leak stack traces, database details, SQL queries, or internal file paths that help attackers map your application internals. In production, a user should see a generic error page, never a raw exception with a stack trace pointing to /app/src/controllers/UserController.java:142.

Test by intentionally triggering errors — submit malformed input, request nonexistent resources, send oversized payloads, and manipulate content types. Check that 404, 500, and other error responses are consistent and reveal nothing about the underlying technology stack. Also verify that error logs capture sufficient detail for debugging without writing sensitive data like passwords or tokens to log files.

Cryptography

Cryptography testing verifies that your application uses current algorithms and key sizes, stores secrets securely, and implements encryption correctly. Test that passwords are hashed with bcrypt, scrypt, or Argon2 — never MD5 or SHA-1. Verify that encryption keys are not hardcoded in source, that TLS certificates are valid and not self-signed in production, and that sensitive data at rest is encrypted with AES-256 or equivalent.

A common failure is using encryption without authentication — AES in CBC mode without an HMAC, for instance, is vulnerable to padding oracle attacks. The Testing Guide walks through specific procedures for identifying these weaknesses.

Business Logic Testing

Business logic flaws are vulnerabilities that exist in the application's workflow rather than in a specific technical control. Examples include bypassing a payment step in a checkout flow, exploiting race conditions in money transfer operations, and manipulating multi-step workflows by replaying or skipping requests.

These flaws are invisible to automated scanners because they require understanding the intended business rules. A DAST tool does not know that transferring a negative amount should be rejected or that applying a discount code twice is a bug. Business logic testing requires manual review of the application's workflow against its requirements.

Client-Side Testing

Client-side testing examines vulnerabilities that execute in the user's browser. Beyond DOM-based XSS, this includes testing for client-side URL redirection (open redirects), CSS injection, cross-origin resource sharing misconfigurations, HTML5 web messaging vulnerabilities, and insecure use of browser storage APIs.

Test that postMessage handlers validate the message origin, that localStorage and sessionStorage do not contain authentication tokens accessible to XSS payloads, and that client-side routing does not expose administrative views to unauthorized users even if the server correctly blocks the underlying API calls.

Applying the Testing Guide in CI/CD Workflows

The Testing Guide was written for manual penetration testers, but most of its test cases can be partially automated and integrated into your DevSecOps pipeline. The key is mapping each testing category to the right automation layer.

Pre-Commit and Pull Request Checks

Run SAST on every pull request to cover Input Validation, Error Handling, and Cryptography categories at the source level. A SAST tool that performs taint analysis catches injection flaws, insecure hashing algorithms, and hardcoded secrets before the code reaches your main branch.

Configure your SAST scanner to fail the PR if it detects high-severity findings in the OWASP-mapped categories. This creates a feedback loop where developers learn the patterns that trigger findings and stop introducing them.

Integration Testing Phase

After your application deploys to a staging environment, run DAST scans to cover Information Gathering, Configuration Management, and Session Management categories. OWASP ZAP's automation framework lets you define scan policies as YAML files, version-control them alongside your application code, and execute them in CI.

A practical pipeline step looks like this: deploy to staging, run ZAP with a baseline scan policy, parse the JSON report for high and medium findings, and gate the deployment if new findings appear. ZAP's baseline scan takes minutes and catches misconfigurations, missing security headers, and common injection flaws without manual intervention.

Periodic Deep Scans

Some testing categories — Business Logic, Authorization, and Identity Management — resist full automation. Schedule periodic manual testing sessions (quarterly or per major release) that use the Testing Guide as a structured checklist. Assign specific test case IDs to testers, track completion, and log findings against the OWASP taxonomy for consistent reporting.

Between manual reviews, use SAST to continuously monitor for regression. If a tester identifies an authorization bypass in a specific controller, write a custom SAST rule that flags similar patterns across the codebase. This turns a point-in-time finding into permanent protection.

Tools Aligned to OWASP Testing

No single tool covers every OWASP testing category. Your security testing tools for web application coverage should combine multiple approaches:

OWASP ZAP — open-source DAST proxy that automates many Testing Guide procedures, including spidering, active scanning for injection flaws, and session analysis. Its automation framework supports CI/CD integration through headless scanning with YAML-defined policies.
Burp Suite — commercial DAST platform with deeper manual testing capabilities, useful for authentication and session management test cases that require human judgment. Its extension ecosystem covers specialized tests like JWT manipulation and GraphQL introspection.
Semgrep — lightweight SAST tool that matches code patterns against security rules. Effective for catching injection flaws and insecure API usage during development. You can write custom rules mapped to specific OWASP test case IDs.
Rafter — SAST platform that runs deep taint analysis and AI-aware code scanning on every pull request, catching vulnerabilities that pattern-matching tools miss. Maps findings directly to OWASP testing categories for clear remediation guidance.
Nuclei — template-based vulnerability scanner useful for configuration and deployment management testing. Its community-maintained template library covers thousands of known misconfigurations.

Map each OWASP testing category to at least one automated tool and document the gaps that require manual review. This coverage matrix becomes your security testing strategy.

How SAST Maps to OWASP Requirements

Static analysis directly addresses multiple OWASP testing categories without running your application. SAST tools trace data flow from user inputs through your code to security-sensitive operations — identifying injection, authentication bypasses, and insecure cryptographic usage at the source level.

SAST is strongest in Input Validation and Error Handling, where it traces tainted data through every code path. It complements DAST tools by catching flaws that only appear in source-level analysis, including dead code paths that external scanners cannot reach.

Beyond injection detection, SAST covers Cryptography testing by flagging deprecated algorithms and weak key sizes in your source. It addresses parts of Authentication testing by detecting insecure password comparison functions, missing rate-limiting middleware, and JWT validation errors. And it catches Authorization flaws when your framework uses declarative access control that a static analyzer can reason about.

The categories where SAST provides the least coverage — Business Logic, Information Gathering, and Configuration Management — are exactly where DAST and manual testing fill the gap. A mature testing program combines both, using the Testing Guide as the framework that ensures nothing falls through the cracks.

Start OWASP-aligned scanning with Rafter →

Scan your code against OWASP categories with Rafter →

OWASP ZAP — open-source DAST proxy that automates many Testing Guide procedures, including spidering, active scanning for injection flaws, and session analysis. Its automation framework supports CI/CD integration through headless scanning with YAML-defined policies.
Burp Suite — commercial DAST platform with deeper manual testing capabilities, useful for authentication and session management test cases that require human judgment. Its extension ecosystem covers specialized tests like JWT manipulation and GraphQL introspection.
Semgrep — lightweight SAST tool that matches code patterns against security rules. Effective for catching injection flaws and insecure API usage during development. You can write custom rules mapped to specific OWASP test case IDs.
Rafter — SAST platform that runs deep taint analysis and AI-aware code scanning on every pull request, catching vulnerabilities that pattern-matching tools miss. Maps findings directly to OWASP testing categories for clear remediation guidance.
Nuclei — template-based vulnerability scanner useful for configuration and deployment management testing. Its community-maintained template library covers thousands of known misconfigurations.

Map each OWASP testing category to at least one automated tool and document the gaps that require manual review. This coverage matrix becomes your security testing strategy.

How SAST Maps to OWASP Requirements

Start OWASP-aligned scanning with Rafter →