OWASP Top 10 for testers, not hackers

You don't need to be a penetration tester to catch security bugs. Most of the OWASP Top 10 shows up in ordinary functional testing — if you know what to look for. This is the tester's translation: each category in plain language, mapped to a flow you already touch, with one concrete check you can run today. It's the conceptual backbone behind everything in auth bugs QA can catch.

The ten, translated

1. Broken Access Control. The big one, and the most testable. Can a user reach or change something they shouldn't? This is IDOR (changing an ID in a URL to see someone else's data) and role/permission gaps. Check: log in as a low-privilege user, grab an admin-only URL or API call, and try it. The server — not the hidden button — must say no.

2. Cryptographic Failures. Sensitive data sent or stored in the clear. Check: watch the network tab — is anything sensitive going over plain HTTP? Are passwords, tokens, or card numbers visible in responses, URLs, or logs?

3. Injection. Untrusted input treated as code — SQL, command, or cross-site scripting. Check: paste ' OR '1'='1 and <script>alert(1)</script> into every input and search box. The app should treat them as literal text, never execute or break on them.

4. Insecure Design. The flaw is in the logic, not a single bug — e.g. a password reset with no rate limit, or a checkout that trusts a client-supplied price. Check: ask "what's the worst thing someone could do by following the rules but with bad intent?" Then try it.

5. Security Misconfiguration. Defaults left on: directory listings, verbose error pages, debug endpoints, stack traces in responses. Check: trigger an error deliberately. Does it leak a stack trace, a SQL query, or an internal path?

6. Vulnerable and Outdated Components. A dependency with a known CVE. Check: this one is mostly tooling — confirm your team runs dependency scanning in CI and that the alerts get triaged, not ignored.

7. Identification and Authentication Failures. Weak login, session, and password-reset handling. Check: does the session actually expire? Does logout invalidate the token server-side? Can you brute-force the login with no lockout?

8. Software and Data Integrity Failures. Trusting data or updates that weren't verified — insecure deserialization, unsigned updates. Check: mostly architectural, but watch for anything that accepts serialized objects or auto-updates from an unverified source.

9. Security Logging and Monitoring Failures. When an attack happens, can anyone tell? Check: do failed logins, permission denials, and suspicious actions get logged? Run a few and ask whether they'd be visible to whoever's on call.

10. Server-Side Request Forgery (SSRF). The server can be tricked into fetching an attacker-chosen URL. Check: anywhere the app takes a URL and fetches it (webhooks, image-from-URL, link previews), try pointing it at an internal address like http://localhost and see if it bites.

What's realistically yours to test

Be honest about the split. As a QA engineer, the four you can meaningfully own with no special tooling are Broken Access Control, Injection, Authentication Failures, and Security Misconfiguration — and those happen to be where the most common, highest-impact bugs live. The rest are partly architectural or tooling-driven; your job there is to know they exist and ask whether someone's covering them.

QA-runnable OWASP checks

• Access control: hit a higher-privilege URL/API as a lower-privilege user — does the server refuse?
• IDOR: change an ID in a URL or request body to one you don't own
• Injection: drop ' OR '1'='1 and <script>alert(1)</script> into every field
• Crypto: scan the network tab for sensitive data over HTTP or in URLs
• Misconfig: force an error — does it leak a stack trace or internal path?
• Auth: confirm sessions expire and logout invalidates the token server-side
• Logging: perform a failed login / denied action — would anyone on call see it?

How to report it

Finding a security issue raises the stakes on the bug report. Don't post a working exploit in a public ticket, don't dump real user data, and describe impact in terms of what an attacker could do rather than just what you typed. The goal is a fix, not a demonstration — keep the report safe and responsible and flag it to whoever owns security triage.