OWASP Top 10 Testing Checklist for Web Apps: A Practical Guide for Software Testing

Security in web applications is not a single feature; it is a set of behaviors that must be verified throughout the lifecycle. This OWASP Top 10 testing checklist for web apps is designed for developers and QA engineers who want focused, repeatable checks that fit into everyday software testing routines. The goal is not to turn testers into penetration experts. It is to make sure the most common risks are covered early, documented clearly, and retested after fixes.

Use the checklist during pull request reviews, sprint testing, and release gates. Each item below includes what to verify, how to test it in a lightweight way, and common signals that something may be wrong. Keep the scope practical: test the authentication flows, the most sensitive APIs, and the pages that handle user input or business data.

1. Broken Access Control

Access control issues happen when users can act outside their intended permissions. Verify that unauthorized actions are blocked consistently.

• What to check: Can a regular user access admin endpoints by changing the URL or request parameters? Can a user modify another user’s data by editing IDs in the request?
• How to test: Create at least two non-admin accounts. Attempt to read, update, or delete resources that belong to the other account. Test direct URL access to protected pages and API routes.
• Signals: Missing server-side checks, inconsistent authorization across similar endpoints, or hidden routes that return data when called directly.

2. Cryptographic Failures

Cryptographic failures include weak algorithms, plaintext storage, and insecure transport. Focus on how sensitive data is protected in transit and at rest.

• What to check: Are all production pages served over HTTPS? Are passwords hashed with a modern, slow algorithm? Are secrets stored outside code and logs?
• How to test: Verify TLS configuration and certificate validity. Check that login and registration endpoints reject plain HTTP. Review password storage format in test environments and confirm no secrets appear in logs or error messages.
• Signals: Use of outdated algorithms, mixed content warnings, or tokens and keys appearing in client-side storage or logs.

3. Injection

Injection flaws occur when untrusted input is used in commands, queries, or templates without proper handling. This includes SQL, NoSQL, OS, and LDAP injection.

• What to check: Do forms and APIs use parameterized queries or safe query builders? Are system calls constructed safely? Is input validated before use?
• How to test: Submit simple payloads such as single quotes, double quotes, and control characters in search, filter, and login fields. Observe error messages and application behavior. Verify that dangerous characters do not change query structure or command execution.
• Signals: Database error strings in responses, unexpected command output, or input directly concatenated into queries or shell commands.

4. Insecure Design

Insecure design is about missing or weak controls at the architecture level. The focus here is whether the application has the right safeguards for its intended use cases.

• What to check: Are high-risk flows protected by rate limits, approval steps, or secondary verification? Are business rules enforced server-side?
• How to test: Walk through critical user journeys such as account creation, password reset, payment, and data export. Attempt to skip steps, replay requests, or abuse legitimate functionality.
• Signals: No rate limits on sensitive endpoints, missing confirmation steps for irreversible actions, or reliance on client-side logic for business rules.

5. Security Misconfiguration

Default settings, open directories, verbose errors, and unnecessary features often create easy attack paths.

• What to check: Are default accounts and credentials disabled? Are directory listings off? Are error pages generic in production? Are unused services and features removed?
• How to test: Request common paths such as /.env, /backup, /debug, and /robots.txt. Review HTTP security headers like Content-Security-Policy, X-Content-Type-Options, and Referrer-Policy. Confirm CORS policy is restrictive and intentional.
• Signals: Exposed configuration files, stack traces in responses, or overly permissive headers and policies.

6. Vulnerable and Outdated Components

Applications often rely on libraries and frameworks with known issues. Keep an inventory and update regularly.

• What to check: Is there a current list of direct and transitive dependencies? Are security updates applied promptly?
• How to test: Run software testing tools that scan dependencies for known vulnerabilities. Compare results against the project’s risk tolerance and patch timelines. Verify that critical fixes are included in release notes and deployment records.
• Signals: Long-unchanged dependency files, repeated findings across sprints, or libraries marked as unmaintained.

7. Identification and Authentication Failures

Weak authentication allows account takeover. Verify the strength of login, session, and password reset mechanisms.

• What to check: Is multi-factor authentication supported for sensitive accounts? Are passwords checked against common lists? Are sessions invalidated after logout and password change?
• How to test: Attempt logins with known weak passwords. Test account lockout or throttling after repeated failures. Confirm session IDs change after reauthentication and that logout truly ends the session.
• Signals: No MFA option, predictable session tokens, or reuse of old session values after logout.

8. Software and Data Integrity Failures

This category covers unsafe deserialization, unsigned updates, and insecure CI/CD pipelines. Focus on whether critical components are verified before execution.

• What to check: Are dependencies and plugins installed from trusted sources with integrity checks? Are deserialization inputs validated and restricted?
• How to test: Review build and deployment scripts for unsigned artifacts. Test data import features with malformed or unexpected payloads. Confirm that auto-update mechanisms verify signatures.
• Signals: Missing integrity hashes, unsigned packages, or deserialization of untrusted data without strict type checks.

9. Security Logging and Monitoring Failures

Without proper logging and monitoring, attacks can go unnoticed. Ensure that security-relevant events are captured and available for review.

• What to check: Are login attempts, access denials, and high-risk actions logged with useful context? Are logs protected from tampering and excessive exposure?
• How to test: Trigger login failures, permission errors, and critical workflow events. Verify that logs include timestamps, user identifiers, and request context. Confirm that logs are shipped to a central system and retained appropriately.
• Signals: Missing logs for key events, sensitive data written to logs, or no alerting on repeated failures.

10. Server-Side Request Forgery (SSRF)

SSRF occurs when an application makes requests to user-controlled URLs without proper validation. This can expose internal systems.

• What to check: Do URL input fields, webhooks, file importers, or document renderers make outbound requests? Are internal addresses blocked?
• How to test: Supply URLs pointing to localhost, private IP ranges, and cloud metadata endpoints. Confirm that the application blocks or sanitizes these targets. Review allowlists and network rules that restrict outbound access.
• Signals: Successful requests to internal addresses, responses that reveal internal service details, or missing egress controls.

How to Use This Checklist in Practice

Treat the list as a baseline, not a one-time exercise. Add these checks to your definition of done for features that handle authentication, user input, payments, or sensitive data. Pair the checklist with lightweight automation where it helps, such as dependency scanning, header checks, and basic input fuzzing. Keep records of test cases, findings, and retest results so progress is visible across sprints.

For larger teams, split responsibilities: developers verify code-level controls during implementation, QA validates end-to-end flows in staging, and security reviews focus on high-risk areas. Revisit the checklist whenever architecture changes, new third-party components are added, or a production incident reveals a gap.

Most importantly, keep the scope realistic. You do not need to cover every edge case in every release. Focus on the paths that carry the most risk, apply consistent checks, and improve coverage over time. A steady, repeatable process will deliver better outcomes than occasional, oversized testing cycles.