SECURITY TESTING
OWASP Top 10 for Testers.
Foundations The OWASP Top 10 translated into practical QA checks — what each risk means, what to verify, safe test ideas, evidence to collect, and when to escalate.
When to use this page: When you want a QA-friendly map of the most common security risks and the concrete checks that catch them before release.
The OWASP Top 10 is a ranked list of the most critical web application security risks. You do not need to be a penetration tester to use it — for QA it is a checklist. Each category translates into negative test cases, boundary checks and response validation you can add to a normal test plan. This page reframes all ten as practical, non-offensive QA checks.
// How to read this page
For each OWASP area you get: what it means in plain language, what QA should check, example symptoms, a safe test idea, evidence to collect, and when to escalate. Keep the framing defensive — you are verifying that a control works, not attacking the application. Use controlled test accounts and approved test environments only.
Safe framing
Say: "Check whether the API rejects access to another user's record." Avoid: "Exploit the endpoint" or "bypass access controls in production." The check is the same; the framing keeps it QA work.
// The Top 10 as QA checks
| OWASP area | What it means | What QA should check | Safe test idea |
|---|---|---|---|
| A01 Broken Access Control | Users reach data or actions they should not. | IDOR, role bypass, hidden pages, direct URL/API access. | As User A, request User B's record by changing the id in the URL or API call — expect 403/404, not 200. |
| A02 Cryptographic Failures | Sensitive data is exposed or weakly protected. | Plain-text secrets, unmasked data, sensitive values in tokens or responses. | Inspect responses, storage and tokens for passwords, card numbers or full personal data that should be masked. |
| A03 Injection | Unsafe input is interpreted as code or a query. | How forms, search and APIs handle special characters and HTML-like input. | Submit safe payloads like a single quote or <script>alert(1)</script> and confirm they are escaped, not executed, and no stack trace leaks. |
| A04 Insecure Design | Missing abuse-case thinking or weak business rules. | Whether limits, ownership and workflow rules are enforced server-side. | Try to skip a required step, reuse a one-time action, or exceed a documented limit and confirm the server refuses. |
| A05 Security Misconfiguration | Debug features, open routes or verbose errors left enabled. | Verbose errors, open admin/debug paths, missing security headers. | Trigger an error and confirm no stack trace or internal path appears; check that /admin and /debug require auth. |
| A06 Vulnerable Components | Known-vulnerable libraries ship to production. | Dependency-scan results and CVE warnings in CI. | Read the SCA/dependency report in the pipeline and flag unresolved high/critical findings — this is a CI check, not a manual payload. |
| A07 Authentication Failures | Weak login, reset or session handling. | Reset-link reuse, missing lockout, sessions valid after logout. | Reset a password, then reuse the old link; log out, then replay the old session token — both should be rejected. |
| A08 Data Integrity Failures | Unsafe uploads or unverified update/import sources. | File-upload validation, import-from-URL features, unsigned update flows. | Upload a blocked file type and a double-extension file and confirm both are rejected by the server, not just the UI. |
| A09 Logging & Monitoring Failures | Risky actions leave no trace. | Whether admin actions, role changes and failed logins are recorded. | Perform a sensitive action (role change, deletion) and confirm an audit-log entry exists with who/what/when. |
| A10 SSRF | The server can be made to fetch attacker-chosen URLs. | URL-fetch, webhook and import-from-URL features. | In an import-from-URL field, enter an internal-looking address (e.g. localhost) and confirm the request is refused or restricted per design. |
// Example symptoms to watch for
- A 200 OK and real data when you expected 401, 403 or 404.
- A button hidden in the UI, but the underlying API still performs the action.
- A stack trace, SQL error, internal hostname or file path in an error message.
- A password-reset or shared link that still works after it should have expired or been used.
- Sensitive values (full card number, full token, another user's email) visible in a response or token payload.
- No audit-log entry after a sensitive admin action.
// Evidence to collect
- The request and response (endpoint, method, status code, relevant body) with sensitive values masked.
- The user role / test account used and the environment.
- Screenshots of the UI state and the network panel.
- A one-line impact summary: what data or action was exposed and to whom.
- Timestamp and any correlation/trace id.
Mask secrets in evidence
Do not paste real passwords, full tokens, production personal data or payment-card data into tickets or screenshots. Mask the middle of the value and keep only what proves the issue.
// When to escalate
- Any access-control finding where one user can read or change another user's data.
- Any sensitive-data exposure (secrets, tokens, personal or payment data).
- Anything you cannot safely confirm without going beyond your agreed test scope — stop and escalate instead.
- Findings on authentication, payments or admin functions — raise these with priority and loop in security/backend early.
Found a security issue?
Use the Security Bug Report Template to capture impact, evidence and escalation notes clearly and safely.
Open the template// Related resources