OWASP Top 10: A Practical Testing Guide

A01: Broken Access Control

Broken access control is the most prevalent web application security risk and the most damaging when exploited. It occurs when users can act outside their intended permissions: accessing another user's data, modifying records they do not own, escalating from a regular account to admin, or bypassing authorization checks entirely.

Testing technique: Horizontal privilege escalation. Log in as User A and note the URLs and API endpoints used to access User A's data. Replace User A's identifiers (account IDs, order numbers, file references) with User B's identifiers. If the application returns User B's data, access control is broken. Test every endpoint that includes a user-specific identifier in the URL, query string, or request body.

Testing technique: Vertical privilege escalation. Log in as a regular user and attempt to access admin-only endpoints by navigating to their URLs directly. Test common paths like /admin, /dashboard, /users, /settings, and any endpoint you discovered during testing. Also test whether modifying role indicators in cookies, JWTs, or request parameters grants higher privileges.

Testing technique: Forced browsing. Attempt to access resources by guessing or enumerating URLs that are not linked from the UI. Try incrementing numeric IDs, replacing UUIDs, and accessing API endpoints that the UI does not call but the server still handles.

Tools: Browser automation with Playwright is the strongest approach for access control testing because tests encode the application's specific role model. OWASP ZAP can detect some access control issues through response comparison, and Burp Suite's Authorize extension automates horizontal privilege testing.

A02: Cryptographic Failures

Cryptographic failures occur when sensitive data is not properly protected, whether in transit, at rest, or in processing. This category covers everything from missing HTTPS to weak password hashing to sensitive data exposed in URLs.

Testing technique: Transport security. Verify that every page and API endpoint uses HTTPS. Test whether the application accepts HTTP connections and whether it redirects to HTTPS. Check the TLS configuration with tools like SSL Labs or testssl.sh, looking for deprecated protocols (TLS 1.0, 1.1), weak cipher suites, and missing HSTS headers.

Testing technique: Data exposure. Examine HTTP responses, error messages, and browser developer tools for sensitive data that should not be visible. Check whether passwords, tokens, or personal data appear in URLs (browser history exposure), in server logs (accessible through log injection or misconfigured endpoints), or in cached pages (accessible to the next user on a shared device).

Testing technique: Password storage. If you have access to the codebase (white-box testing), verify that passwords are hashed with bcrypt, scrypt, or Argon2 with adequate cost factors. If testing from outside (black-box), check whether the application allows extremely long passwords (a sign of proper hashing, since fixed-output hash functions handle any length) or rejects them (a sign of length-limited storage, possibly plain text).

Tools: SSL Labs and testssl.sh for TLS configuration. OWASP ZAP's passive scanner catches many header-level issues. SAST tools (Semgrep, CodeQL) catch weak cryptographic function calls in code.

A03: Injection

Injection vulnerabilities occur when user-supplied data is sent to an interpreter (SQL engine, OS shell, LDAP server, template engine) without proper sanitization. The attacker's input is treated as code rather than data, allowing them to execute arbitrary commands.

Testing technique: SQL injection. Submit SQL-specific characters and payloads to every input field: single quotes ('), double quotes ("), comment sequences (--), boolean tests (1=1), UNION SELECT statements, and time-delay payloads (SLEEP(5)). Observe whether the application returns error messages, behaves differently, or delays its response. Our SQL injection testing guide covers this in full depth.

Testing technique: Cross-site scripting (XSS). Submit script payloads to input fields, URL parameters, and headers. Test for reflected XSS (the payload appears in the immediate response), stored XSS (the payload is saved and rendered later), and DOM-based XSS (the payload is processed by client-side JavaScript). Use payloads that test for different contexts: HTML body, HTML attributes, JavaScript strings, and URL contexts each require different escape sequences. Our XSS testing guide covers these techniques.

Testing technique: Command injection. If the application interacts with the OS (file operations, network utilities, system commands), test whether user input reaches the shell. Submit payloads that chain commands: semicolons (;whoami), pipes (|id), backticks (`id`), and $() substitution. Test blind command injection by triggering time delays or DNS lookups.

Tools: OWASP ZAP and Burp Suite both include extensive injection testing capabilities. SQLMap automates SQL injection detection and exploitation. Semgrep catches injection patterns in source code.

A04: Insecure Design

Insecure design is about flaws in the application's architecture that cannot be fixed by better coding. It requires threat modeling: analyzing the application's design assumptions and identifying scenarios where those assumptions can be violated.

Testing technique: Abuse case analysis. For each feature, ask "what is the worst thing a user could do with this?" A file upload feature might allow uploading a web shell. A referral program might allow self-referral. A password reset flow might allow account takeover through email enumeration. Document these abuse cases and test each one.

Testing technique: Rate limiting verification. Test whether critical endpoints enforce rate limits. Submit 100 login attempts in rapid succession. Submit 100 password reset requests for the same account. Submit 100 signup requests. If none of these trigger any blocking or throttling, the application is vulnerable to brute-force and resource exhaustion attacks.

Testing technique: Workflow bypass. Map the application's multi-step workflows (checkout, registration, verification) and test whether any step can be skipped by navigating directly to a later step. Try completing a purchase without payment, verifying an account without the verification token, or accessing premium content without a subscription.

Tools: Threat modeling tools (OWASP Threat Dragon, Microsoft Threat Modeling Tool) help identify design-level risks. Browser automation tools test workflow bypasses. There is no automated scanner for insecure design because it is inherently application-specific.

A05: Security Misconfiguration

Security misconfiguration is the broadest category and often the easiest to test for. It covers default settings, unnecessary features, verbose errors, missing hardening, and any configuration that weakens security.

Testing technique: Default credential scanning. Test whether the application or its infrastructure components (databases, admin panels, cloud dashboards) still use default usernames and passwords. Common defaults include admin/admin, root/root, admin/password, and blank passwords. Nuclei templates cover thousands of known default credentials.

Testing technique: Security header analysis. Check every HTTP response for security headers. The essential headers are: Content-Security-Policy (restricts script sources), Strict-Transport-Security (forces HTTPS), X-Content-Type-Options (prevents MIME sniffing), X-Frame-Options or CSP frame-ancestors (prevents clickjacking), and Referrer-Policy (controls referrer leakage). Missing headers are easy to check and common to find.

Testing technique: Error handling review. Trigger errors by sending invalid input, requesting nonexistent resources, and violating input constraints. Check whether error responses reveal stack traces, database queries, file paths, framework versions, or other internal details that help an attacker understand the application's internals.

Testing technique: Unnecessary features. Check whether debug endpoints, test pages, admin installers, or sample applications are accessible. Test for common paths like /debug, /test, /install, /status, /health, /phpinfo, and /server-info. These are often left enabled after development and provide detailed information about the server environment.

Tools: OWASP ZAP and Nikto excel at configuration testing. Nuclei's template library covers thousands of known misconfigurations. Cloud security posture management (CSPM) tools check cloud infrastructure configurations.

A06: Vulnerable and Outdated Components

Every library, framework, and platform the application uses is a potential source of vulnerabilities. When a dependency has a known CVE, every application that uses it is vulnerable until updated.

Testing technique: Dependency audit. Run package manager audit commands: npm audit for Node.js, pip-audit for Python, mvn dependency-check:check for Java. These compare installed versions against vulnerability databases and report findings with severity levels. Any critical or high severity finding should be addressed before release.

Testing technique: Version detection. For black-box testing, identify the application's technology stack from response headers (Server, X-Powered-By), error messages, and client-side code. Compare detected versions against known vulnerability databases. Wappalyzer (browser extension) and Nuclei (tech detection templates) automate technology identification.

Tools: Snyk, Dependabot, npm audit, pip-audit, OWASP Dependency-Check, and Retire.js. These are the most mature category of security testing tools because the problem (matching versions to CVEs) is well-defined and automatable.

A07: Identification and Authentication Failures

Authentication failures allow attackers to compromise passwords, session tokens, or keys, or to assume other users' identities.

Testing technique: Credential testing. Test password policies: does the application allow "password1" or "123456"? Does it enforce minimum length (8+ characters), complexity, or check against known breached passwords? Test whether the login form reveals which field is wrong ("username not found" vs "incorrect password" leaks which usernames exist).

Testing technique: Session management. Examine session tokens for sufficient randomness (long, unpredictable values). Test whether sessions expire after a reasonable idle period. Test whether logging out actually invalidates the session token server-side (capture the token before logout, then replay it). Test whether sessions are invalidated after password change. Check cookie flags: HttpOnly (prevents JavaScript access), Secure (HTTPS only), SameSite (prevents CSRF).

Testing technique: Brute force resistance. Submit many failed login attempts in rapid succession. Check whether the application locks the account, introduces delays, or presents a CAPTCHA. If the application allows unlimited attempts with no throttling, it is vulnerable to automated credential stuffing with stolen password databases.

Tools: Playwright and Selenium for scripting authentication test scenarios. Burp Suite Intruder for credential testing. OWASP ZAP for session token analysis.

A08: Software and Data Integrity Failures

This category covers the assumption that code and data have not been tampered with. It includes CI/CD pipeline security, unsigned auto-updates, and insecure deserialization.

Testing technique: CI/CD security review. Review the CI/CD pipeline for weaknesses: are secrets stored as encrypted environment variables? Are build scripts pulled from version control (not editable by external contributors without review)? Are deployment credentials scoped to minimum necessary permissions? Can a compromised dependency inject code into the build?

Testing technique: Deserialization testing. If the application accepts serialized data (Java serialized objects, Python pickle, PHP serialize), test whether it validates the data before deserializing. Submit modified serialized payloads that include object types the application should not instantiate. Deserialization vulnerabilities can lead to remote code execution.

Tools: Ysoserial for Java deserialization testing. SAST tools for detecting deserialization of untrusted data in code. CI/CD security scanners for pipeline review.

A09: Security Logging and Monitoring Failures

Without logging and monitoring, security breaches go undetected, and post-incident investigation is impossible.

Testing technique: Log coverage. Trigger events that should be logged: failed logins, access denied responses, input validation failures, privilege escalation attempts. Then verify that these events appear in the application's security logs with sufficient detail (timestamp, user, action, IP address, outcome).

Testing technique: Alerting verification. Trigger events that should generate alerts: multiple failed logins from the same IP, successful login from an unusual location, admin actions by a newly created account. Verify that alerts fire within an acceptable time window and reach the right people.

Testing technique: Log injection. Submit log-injection payloads in user input: newline characters followed by fake log entries. If the application writes user input to logs without sanitization, an attacker can inject misleading log entries that cover their tracks or implicate innocent users.

Tools: This category requires manual testing because it evaluates processes and configurations rather than code. Log management platforms (ELK, Splunk, Datadog) provide the infrastructure, and security testing verifies that it is properly configured.

A10: Server-Side Request Forgery (SSRF)

SSRF occurs when the application fetches remote resources based on user-supplied URLs without validating the destination. An attacker can make the server send requests to internal services, cloud metadata endpoints, or other targets that should not be accessible from outside.

Testing technique: Internal resource access. If the application accepts a URL as input (image URL, webhook URL, import URL), submit internal addresses: http://127.0.0.1, http://localhost, http://169.254.169.254 (AWS metadata), http://metadata.google.internal (GCP metadata). If the application fetches and returns the content, SSRF is confirmed.

Testing technique: Port scanning. Submit URLs with different port numbers targeting localhost: http://127.0.0.1:22, http://127.0.0.1:3306, http://127.0.0.1:6379. Different response times or error messages for open vs closed ports allow an attacker to map the internal network through the vulnerable application.

Testing technique: DNS rebinding. Use a DNS rebinding service that initially resolves to an allowed external IP but switches to an internal IP after the application's validation check passes. This bypasses URL allowlist checks that resolve the hostname at validation time but use the resolved IP at fetch time.

Tools: Burp Suite Collaborator for out-of-band SSRF detection. OWASP ZAP with SSRF scan rules. SSRFmap for automated SSRF exploitation testing.

Prioritizing Your OWASP Testing

Testing for all ten categories is the goal, but teams with limited resources should prioritize by impact and likelihood. Start with A01 (Broken Access Control) and A03 (Injection) because they are the most common and most exploitable. Add A07 (Authentication) and A05 (Misconfiguration) next because they are easy to test and frequently found. Address the remaining categories as your security testing program matures.

Automated tools handle A03 (Injection), A05 (Misconfiguration), and A06 (Outdated Components) well. A01 (Access Control), A04 (Insecure Design), and A07 (Authentication) benefit most from manual and application-specific testing. Layer both approaches for the most thorough coverage.