What is the OWASP Top 10 and what can QA test from it?

The OWASP Top 10 is a document published by the Open Worldwide Application Security Project that ranks the most critical security risks for web applications. It is an awareness document, not a complete standard: it tells you where real applications most often go wrong. It is revised every few years based on contributed data and community input, and the current edition is the OWASP Top 10:2025. Mention that categories and their order change between editions (for detailed verification requirements, OWASP’s ASVS is the more complete reference).

The 2025 categories

You do not need to recite the exact ranking, but you should recognise the categories:

• A01 Broken access control: users can act outside their permissions, for example reading another user’s order by changing an ID. In 2025 this also covers server-side request forgery (SSRF), which was a separate category in 2021.
• A02 Security misconfiguration: default credentials, debug endpoints, open cloud storage, missing security headers.
• A03 Software supply chain failures (new): vulnerable or compromised dependencies, build tools and CI/CD pipelines. It broadens 2021’s “vulnerable and outdated components”.
• A04 Cryptographic failures: sensitive data sent or stored without proper encryption.
• A05 Injection: SQL, NoSQL, OS command injection and cross-site scripting, where untrusted input is interpreted as code.
• A06 Insecure design: missing controls at the design level, such as no limit on password reset attempts.
• A07 Authentication failures: weak session handling, credential stuffing not prevented.
• A08 Software or data integrity failures: trusting updates, scripts or client data without verifying them.
• A09 Security logging and alerting failures: attacks are not logged, or nobody is alerted.
• A10 Mishandling of exceptional conditions (new): errors and unusual situations that are not prevented, detected or handled safely.

What a QA engineer can realistically test

Most of these are testable with the same skills you use for functional testing, applied with an attacker’s mindset:

• Authorization: log in as user A, capture a request, replay it with user B’s resource ID. Try calling admin endpoints with a normal user’s token.
• Authentication and sessions: does logout invalidate the session server-side? Do password reset tokens expire and work only once? Is there lockout or rate limiting on login?
• Input handling: submit quotes, script tags and very long strings in every field and API parameter, and check the response is rejected or safely encoded rather than executed or causing a 500.
• Error handling and exceptional conditions: errors should not leak stack traces, SQL fragments or internal hostnames. Malformed requests, timeouts and failures halfway through a flow should fail closed (deny access, roll back the transaction) rather than fail open, and errors should come back in a consistent format.
• Supply chain: check that the lockfile is committed and used in CI, versions are pinned, dependency scanning (such as npm audit or OWASP Dependency-Check) runs on every change, and the team can produce an SBOM. Apply the same rules to the test framework’s own dependencies.
• Configuration: check responses for headers such as Content-Security-Policy, Strict-Transport-Security and X-Content-Type-Options, and that cookies carry Secure, HttpOnly and a sensible SameSite value.
• Sensitive data: personal data should not appear in URLs, logs or client-side storage.

Where QA stops

Functional security checks raise the floor, but they do not replace a penetration test, threat modelling or automated scanning (SAST, DAST, dependency scanning). A good answer positions QA as a partner of the security team: you know the business flows best, so you are well placed to spot authorization gaps and broken failure paths that scanners cannot understand. And you only test systems you are authorised to test.

What interviewers look for

• You describe the Top 10 as a risk awareness list, not a checklist that guarantees security.
• You know the current edition is 2025 and can name what is new in it.
• You can name several categories and explain at least one with a concrete example.
• You translate categories into test cases you could run this week.
• You are honest about where specialist security testing takes over.

Common mistakes

• Reciting category names with no idea how to test them.
• Quoting the 2021 list as current (for example, SSRF as A10).
• Claiming that passing a scanner run means the app is secure.