The OWASP Top 10 for Testers

Every QA engineer working on web applications needs a security checklist. The OWASP Top 10 is that checklist — the most authoritative, most widely used reference for the critical vulnerability categories that affect real applications. Understanding it does not make you a penetration tester. It does make you a substantially better QA engineer.

What OWASP is

OWASP (Open Web Application Security Project) is a non-profit that publishes free security guidance used by developers, QA engineers, and security professionals worldwide. Their Top 10 — a ranked list of the most critical web application security risks — is updated every three to four years based on data from hundreds of organisations and thousands of real applications. The current edition is OWASP Top 10 2021.

The Top 10, ranked by prevalence

Here is what each category means and what a QA tester should look for:

A01 — Broken Access Control. Users can access resources, pages, or data they should not be able to reach. This is the most prevalent category in the Top 10. Test by: logging in as a standard user and trying to access /admin. Changing a resource ID in the URL from /profile/1 to /profile/2. Calling API endpoints your role is not supposed to have access to.

A02 — Cryptographic Failures. Sensitive data is transmitted or stored without proper protection. Check: is the site using HTTPS? Are passwords stored hashed (not plaintext)? Is sensitive data (credit card numbers, personal information) encrypted at rest and in transit?

A03 — Injection. Attacker-controlled data is interpreted as a command by a database, OS, or browser. SQL injection, NoSQL injection, command injection, and Cross-Site Scripting (XSS) all fall here. Test: try entering ' OR '1'='1 in login fields. Try <script>alert(1)</script> in search and comment fields.

A04 — Insecure Design. Flaws in the architecture or design of the system — not implementation bugs. Examples: no rate limiting on login (allows brute force), no MFA option for sensitive accounts, business logic that can be gamed. These require design-level fixes, not code patches.

A05 — Security Misconfiguration. Default settings, verbose error messages, exposed admin pages, unnecessary open ports. Test: try accessing /admin, /.git, /.env. Check whether error responses include stack traces or database details.

A06 — Vulnerable and Outdated Components. Using libraries, frameworks, or dependencies with known CVEs. This is largely caught by automated tools (Snyk, Dependabot) running in CI rather than manual testing, but QA engineers should know it exists.

A07 — Identification and Authentication Failures. Weak password policies, sessions that never expire, logout that does not invalidate the session, poor password reset flows. Test: does the app accept "password123"? Does logging out actually kill the session token?

A08 — Software and Data Integrity Failures. Applications that trust data without verifying it — insecure deserialisation, plugins or updates fetched without signature verification. Complex to test manually; usually requires security-specialist involvement.

A09 — Security Logging and Monitoring Failures. The application does not log security-relevant events (failed logins, access denied) or does not alert on suspicious patterns. Test by simulating an attack (10 failed logins in a row) and checking whether any alert fires or log entry appears.

A10 — Server-Side Request Forgery (SSRF). An attacker causes the server to make HTTP requests to an unintended destination — for example, to internal services on the private network. Test: if any feature accepts a URL as input, try http://169.254.169.254/ (AWS metadata endpoint) or http://localhost/admin.

Using the Top 10 as a testing checklist

The practical value of the OWASP Top 10 is that it turns "security testing" from an intimidating open-ended discipline into a structured checklist. Before any release, walk through the ten categories and ask: have we tested for this? Can we demonstrate the system is not vulnerable?

Not all ten are equally applicable to every application. A static marketing site has a different risk profile from a financial services API. Use the list as a thinking tool — prioritise the categories most relevant to your product's attack surface.

⚠️ Common mistakes

• Skipping A01 because it seems obvious. Broken Access Control is the number one vulnerability category precisely because developers assume their authorisation checks are working when they are not. Test it explicitly on every role and every endpoint.
• Treating the Top 10 as a complete security testing programme. The Top 10 covers the most common categories — not all categories. A penetration test by a specialist will find issues the Top 10 checklist does not specifically address. Use it as a baseline, not a ceiling.
• Only running automated scans and calling it done. Tools like OWASP ZAP and Burp catch some categories (injection, misconfiguration) well. Others (insecure design, broken access control) require manual testing with specific user roles and scenarios.

🎯 Practice task

Pick a web application you have legitimate access to test — a staging environment, a personal project, or an application you have explicit permission to assess.

1. Work through A01, A03, A05, and A07 — the four most commonly tested manually.
2. For each, write one specific test you would run and what result would indicate a vulnerability.
3. Run any two of those tests and document what you observe — pass, fail, or inconclusive.

This exercise connects the abstract list to concrete, reproducible test cases. The next lesson goes deeper on three of the most common vulnerability types: XSS, SQL injection, and CSRF.