Security testing sounds like a separate discipline, but most of the OWASP Top 10 maps cleanly onto test cases a QA engineer already knows how to write. Here's the reframe.
A01: Broken Access Control
The single most common real-world issue. As QA, you test it by changing roles and IDs:
- Log in as a normal user, call an admin endpoint directly.
- Change a resource ID in the URL to one you don't own.
- Remove the auth token entirely and retry.
If a standard user reaches admin data, that's broken access control — and it's just a negative test case.
A03: Injection
You already test invalid input. Add the security payloads:
SQL: ' OR '1'='1
XSS:
Drop them in every field and URL parameter. If the SQL one logs you in or the XSS one pops an alert, you've found injection.
A02: Cryptographic Failures
Check the boring basics:
| Check | How |
| HTTPS everywhere | Watch for http:// requests in DevTools |
| Passwords not in responses | Inspect the network tab after login |
| Tokens not in the URL | URLs get logged and shared |
A05: Security Misconfiguration
- Default credentials still working (
admin/admin) - Detailed stack traces shown to users
- Directory listing enabled
- Debug endpoints reachable in production
A07: Identification & Authentication Failures
Test the auth flow like an attacker:
- Does login lock out after many failed attempts?
- Can you reuse a password reset link twice?
- Does the session expire, and does logout actually invalidate it server-side?
The Point
You don't need a new title to test these. Every item above is a negative test case with a security flavor. Adding them to your existing test design catches the bugs that hurt most — and makes you the tester developers actually want on a release.