OWASP Top 10 Testing Guide: How to Test for Each Vulnerability

The OWASP Top 10 is the most recognized framework for web application security risk. Published by the Open Web Application Security Project and updated to reflect real-world attack data, it represents the most critical security risks facing web applications today. If you understand how to test for each category, you understand the fundamentals of web application security.

This guide explains each OWASP Top 10 category (2021 edition, the current standard), how attackers exploit them, how to test for them, and how to fix them. It's designed for developers, security engineers, and QA professionals who want to understand web application risk rather than just memorize a list.

A01: Broken Access Control

Access control enforces that users can only act within their intended permissions. Broken access control means users can act outside those permissions — accessing other users' data, accessing admin functionality, or performing unauthorized operations.

Common manifestations:

• Insecure Direct Object References (IDOR): changing user_id=123 to user_id=124 in a URL to access another user's data
• Missing function-level access control: accessing /admin/users without being an admin
• Privilege escalation: modifying a request to include "role":"admin" and having it accepted
• CORS misconfiguration allowing unauthorized cross-origin access
• Force browsing to authenticated pages without authentication

How to test:

1. Map all application endpoints and identify which require authentication and what authorization level
2. Test each endpoint with a lower-privilege account (or unauthenticated) than the endpoint requires
3. Test IDOR: create two accounts at the same privilege level, authenticate as Account A, then attempt to access or modify Account B's resources using Account B's resource IDs
4. Test parameter modification: add admin=true, role=admin, or isAdmin=1 to requests and observe behavior
5. Check API endpoints independently — the UI may prevent unauthorized access, but the API backing it may not
6. Use Burp Suite's Autorize extension to automate horizontal and vertical privilege testing across all observed requests

Tools: Burp Suite (Autorize extension), manual testing, OWASP ZAP

Remediation:

• Enforce access control server-side on every request — never trust client-provided role or permission data
• Deny by default: any resource not explicitly permitted should be denied
• Use indirect object references (UUIDs instead of sequential integers) to make guessing harder
• Log access control failures and alert on repeated violations
• Test access control in automated test suites on every deployment

A02: Cryptographic Failures

Previously called "Sensitive Data Exposure," this category covers failures in cryptography that expose sensitive data. Most commonly: data transmitted or stored without encryption, or encrypted with weak algorithms.

Common manifestations:

• Sensitive data transmitted over HTTP (not HTTPS)
• Passwords stored as plaintext or with weak hashing (MD5, SHA1)
• Sensitive data stored in browser storage (localStorage, sessionStorage)
• Weak or outdated TLS versions (TLS 1.0, 1.1)
• Hardcoded cryptographic keys or secrets in source code
• Predictable initialization vectors in encryption

How to test:

1. Check all traffic with a proxy (Burp Suite, ZAP) — confirm everything uses HTTPS, including redirects from HTTP
2. Test SSL/TLS configuration with SSL Labs (ssllabs.com/ssltest/) — grade should be A or A+
3. Attempt to access the application over HTTP — it should redirect to HTTPS, not serve content
4. Check HTTP response headers for Strict-Transport-Security (HSTS)
5. Search for sensitive data in client-side storage: browser DevTools → Application → Local Storage, Session Storage, Cookies
6. Check cookies for the Secure flag
7. Search the codebase for hardcoded secrets: API keys, connection strings, passwords
8. Test password reset and registration to verify passwords are never returned in responses

Tools: SSL Labs, Burp Suite, browser DevTools, git-secrets / truffleHog for code scanning

Remediation:

• Use TLS 1.2 or 1.3 for all connections; disable older versions
• Hash passwords with bcrypt, Argon2, or scrypt — never MD5 or SHA1
• Enable HSTS with a long max-age
• Store secrets in environment variables or secrets managers — never in code
• Classify data by sensitivity and apply appropriate encryption

A03: Injection

Injection flaws occur when untrusted data is sent to an interpreter as part of a command or query. The interpreter executes the attacker-controlled data as code. SQL injection is the most well-known example, but the category covers OS command injection, LDAP injection, XPath injection, and others.

Common manifestations:

• SQL injection via form fields, URL parameters, or HTTP headers
• OS command injection via file upload names, system commands constructed from user input
• LDAP injection in directory-based authentication
• Server-side template injection (SSTI)

How to test:

1. Identify all input vectors: form fields, URL parameters, HTTP headers (User-Agent, Referer, X-Forwarded-For), JSON fields, cookies
2. Test for SQL injection manually: enter a single quote ', double dash --, and semicolons to observe errors or behavior changes
3. Use sqlmap for automated SQL injection detection against suspected endpoints
4. Test for SSTI by entering template expressions: {{7*7}}, ${7*7} — if the response contains 49, template injection exists
5. For command injection, test inputs that might be passed to system commands with: ; ls, | whoami
6. Review code for dynamic query construction — any string concatenation into SQL, shell commands, or LDAP queries is a red flag

Tools: sqlmap, Burp Suite (Intruder for payload fuzzing), OWASP ZAP

Remediation:

• Use parameterized queries (prepared statements) for all database queries — no exceptions
• Use ORMs correctly and understand when they fall through to raw queries
• Validate and sanitize all inputs; prefer allowlisting
• Run the application database user with minimum required permissions
• Use stored procedures carefully — they can still be vulnerable if constructed dynamically

A04: Insecure Design

Insecure design covers vulnerabilities that arise from missing or ineffective security controls in the design phase — not implementation bugs, but flawed security architecture. This category was added in 2021 to distinguish design failures from implementation failures.

Common manifestations:

• Password reset via security questions (guessable, phishable)
• "Remember me" functionality that never expires
• Business logic that allows bulk data enumeration
• Features designed without rate limiting or abuse prevention
• Missing separation between test and production environments

How to test:

1. Review threat models (if they exist) — are threats identified during design actually mitigated?
2. Test for abuse of expected functionality: apply discount codes multiple times, transfer funds in unexpected sequences, submit forms multiple times rapidly
3. Test rate limiting on high-value flows: registration, password reset, login, API calls
4. Review business logic: is there any way to skip required steps in a multi-step process?
5. Test for resource exhaustion: can a user trigger expensive operations at scale without restriction?

Tools: Manual testing, Burp Suite for flow manipulation

Remediation:

• Threat model during design, not after implementation
• Use established design patterns for authentication, authorization, and session management
• Define and enforce rate limits for all user-accessible flows
• Design API quotas before building the API, not after abuse occurs

A05: Security Misconfiguration

Security misconfiguration is the most commonly occurring vulnerability and covers a broad range of configuration failures: default credentials, unnecessary features enabled, verbose error messages, missing security headers, and unpatched systems.

Common manifestations:

• Default credentials on admin panels, network devices, or databases
• Verbose error messages exposing stack traces, database schemas, or file paths
• Directory listing enabled on web servers
• Unnecessary services or ports exposed
• Missing security headers (CSP, HSTS, X-Frame-Options)
• Cloud storage buckets publicly accessible

How to test:

1. Check security headers at securityheaders.com or via Burp Suite/ZAP
2. Access common admin paths: /admin, /phpmyadmin, /wp-admin, /console, /.env, /config.php
3. Trigger error conditions deliberately and observe responses — do they reveal internal paths, stack traces, or database errors?
4. Check for directory listing: navigate to directories directly (e.g., /images/, /uploads/)
5. Run Nikto for server-level misconfiguration checks
6. Test with default credentials on any identified software: admin/admin, admin/password
7. Use Google Dorks to find exposed configuration files indexed by search engines

Tools: Nikto, Burp Suite, securityheaders.com, SSL Labs, manual testing

Remediation:

• Implement a hardening process for all environments — no manual configuration without documented defaults
• Disable or remove unused features, services, and default accounts
• Configure error handling to show generic messages to users; log details server-side
• Set all required security headers
• Run security scans after every configuration change

A06: Vulnerable and Outdated Components

Modern applications depend on hundreds of third-party components — libraries, frameworks, modules, and container images. Using components with known vulnerabilities exposes your application to attacks that require no discovery — just a scan against a vulnerability database.

Common manifestations:

• Outdated npm, pip, Maven, or NuGet dependencies with known CVEs
• End-of-life software (old Node.js versions, outdated Linux distros)
• Container images based on vulnerable base images
• CMS plugins and themes not kept up to date

How to test:

1. Run npm audit (Node.js), pip-audit (Python), or equivalent for your stack
2. Use OWASP Dependency-Check for a language-agnostic scan
3. Scan container images with Trivy: trivy image myapp:latest
4. Identify CMS plugins and themes in use and check them against CVE databases
5. Check your application server, web server, and OS versions for end-of-life status
6. Review your software bill of materials (SBOM) against the National Vulnerability Database

Tools: npm audit, pip-audit, OWASP Dependency-Check, Snyk, Trivy, Grype

Remediation:

• Integrate dependency scanning into CI/CD — block deployments on critical/high CVEs
• Maintain a software bill of materials (SBOM)
• Set up automated dependency update PRs (Dependabot, Renovate)
• Subscribe to security advisories for your key dependencies

A07: Identification and Authentication Failures

Formerly "Broken Authentication," this covers weaknesses in how applications verify user identity and manage sessions.

Common manifestations:

• No brute force protection on login endpoints
• Weak or predictable session token generation
• Session tokens exposed in URLs
• Passwords not checked against known breached lists
• Missing MFA for high-privilege accounts
• Session not invalidated on logout

How to test:

1. Attempt to brute force login: use Burp Intruder with a common password list and observe if requests are blocked after N attempts
2. Examine session token format and entropy: are tokens sequential, predictable, or short?
3. Test session after logout: copy the session cookie before logout, log out, then try using the old cookie
4. Test session fixation: set a session cookie before logging in — does the server issue a new token post-authentication?
5. Test concurrent sessions: log in from two browsers simultaneously and verify both sessions remain valid (or that policy is enforced)
6. Test password policy: attempt to register with short, common, or breached passwords
7. Test MFA bypass: attempt to skip MFA steps by directly accessing post-MFA URLs

Tools: Burp Suite (Intruder, Sequencer for token analysis), manual testing

Remediation:

• Implement lockout or progressive delay after failed login attempts
• Generate session tokens with a CSPRNG; use a proven session management library
• Invalidate sessions server-side on logout and password change
• Implement MFA for all users; require it for admin accounts
• Check new passwords against HaveIBeenPwned or similar breached password lists

A08: Software and Data Integrity Failures

This category covers assumptions about software updates, CI/CD pipelines, and critical data that aren't verified for integrity. The SolarWinds attack is a high-profile example: malicious code injected into a legitimate software update process and distributed to thousands of organizations.

Common manifestations:

• Unsigned software updates that can be tampered with
• Insecure deserialization of untrusted data
• CI/CD pipeline compromised to inject malicious code
• Libraries loaded from CDNs without Subresource Integrity (SRI) checks

How to test:

1. Check CDN-hosted scripts for SRI attributes — if the integrity attribute is missing, the script can be tampered with at the CDN level
2. Test deserialization endpoints: send malformed serialized objects and observe behavior; errors exposing class names suggest exploitable deserialization
3. Review CI/CD pipeline access controls: who can modify pipeline definitions, and are secrets properly scoped?
4. Check update mechanisms for signature verification

Tools: Browser DevTools (inspect script tags), Burp Suite, manual pipeline review

Remediation:

• Add SRI checks to all externally hosted scripts and stylesheets
• Use digital signatures for software updates and verify them before applying
• Restrict write access to CI/CD pipeline configurations
• Avoid deserialization of data from untrusted sources; use safe data formats like JSON instead of language-native serialization

A09: Security Logging and Monitoring Failures

You cannot respond to attacks you cannot detect. This category covers insufficient logging, monitoring, and incident response capability — not an active vulnerability, but a failure that allows attackers to persist undetected.

Common manifestations:

• Authentication failures not logged
• No alerting on repeated failed login attempts
• Application logs containing sensitive data (passwords, tokens in plaintext)
• Logs that don't include enough context to reconstruct an incident
• No monitoring or alerting on security-relevant events

How to test:

1. Perform clearly suspicious actions (repeated failed logins, accessing admin paths, parameter tampering) and verify they appear in logs
2. Review log format: do logs include timestamp, user identity, source IP, action, and result?
3. Check that sensitive data is not logged: trigger authentication flows and review logs for passwords or tokens
4. Test alerting: perform a threshold number of failed logins and verify an alert fires
5. Verify log integrity: are logs stored where application code cannot modify or delete them?

Tools: Manual testing plus log review, SIEM review

Remediation:

• Log all authentication events (success and failure) with full context
• Log access control failures
• Generate alerts on threshold events (failed logins, admin access, large data exports)
• Use centralized, tamper-resistant log storage
• Define and test an incident response plan before you need it

A10: Server-Side Request Forgery (SSRF)

SSRF vulnerabilities allow attackers to induce the server-side application to make HTTP requests to an arbitrary domain. This is particularly dangerous in cloud environments where instance metadata services (AWS IMDSv1, GCP metadata server) are accessible from the instance and can expose credentials.

Common manifestations:

• URL-fetching features (preview URL content, import from URL, webhook testing) that don't validate the target URL
• Image loading, PDF generation, or report generation that accepts user-supplied URLs
• Cloud environments where the instance can access internal metadata services

How to test:

1. Identify all features that accept URLs as input: webhook configuration, URL preview, image import, PDF generation
2. Point the URL at internal resources: http://localhost:8080/admin, http://10.0.0.1/, http://169.254.169.254/latest/meta-data/ (AWS metadata endpoint)
3. Use an out-of-band testing service (Burp Collaborator, interactsh) to detect blind SSRF where responses aren't returned to the client
4. Test URL validation bypasses: decimal IP representations, URL-encoded characters, and redirect chains

Tools: Burp Suite (Collaborator for blind SSRF), interactsh, manual testing

Remediation:

• Validate and allowlist URLs if the feature has a defined set of permitted domains
• Block requests to private IP ranges (RFC 1918 addresses and link-local addresses)
• Use IMDSv2 (token-based) instead of IMDSv1 on AWS to protect instance metadata
• Don't return raw server responses from URL-fetching features to clients

Building OWASP Top 10 Testing into Your Workflow

Testing for OWASP Top 10 vulnerabilities should not be an annual event. It should be part of your continuous development workflow.

During development: Write code with these patterns in mind. Use parameterized queries. Validate inputs server-side. Set security headers. Enforce access control at the data layer.

During code review: Add OWASP-specific review criteria to your PR checklist. Any code that touches authentication, authorization, data access, or external requests gets OWASP-aware review.

In your CI/CD pipeline: Automate what can be automated — dependency scanning, SAST, security header checks, and authentication flow tests. Platforms like HelpMeTest let you write security regression tests in natural language using Robot Framework and Playwright, and run them on every deployment. This ensures that controls verified today don't regress as your application evolves.

Periodically: Run OWASP ZAP against staging environments on a schedule. Commission penetration tests that specifically target OWASP Top 10 categories for your application's specific risk profile.

The OWASP Top 10 doesn't change quickly because the underlying vulnerability patterns are fundamental. Broken access control, injection, and cryptographic failures have appeared in every edition because they reflect how applications are built and how they consistently fail. Understanding how to test for each category gives you a durable foundation for building and evaluating secure applications.

Conclusion

The OWASP Top 10 is a map of where web application security fails most consistently. Each category represents a class of vulnerabilities with known patterns, testable behaviors, and documented remediations. Working through this guide systematically — testing each category in your application, fixing what you find, and automating checks to prevent regression — puts you well ahead of the vast majority of applications in production.

Security is not a feature you add at the end. It's a property of how you build, test, and operate software. The OWASP Top 10 is the clearest available guide to where to start.