The OWASP Top 10 is a widely used awareness list of the most critical security risks for web applications, published by the Open Worldwide Application Security Project. Developers use it to write safer code; testers use it to plan security tests; auditors use it as a baseline. The list below follows the 2021 edition, which is still the most referenced version.
A01: Broken Access Control
Users can act outside their permissions.
- Example: changing
/invoice?id=1001toid=1002shows another customer's invoice (an IDOR: Insecure Direct Object Reference). - Prevent: check permissions on the server for every request; deny by default; never rely on hidden buttons in the UI.
A02: Cryptographic Failures
Sensitive data is exposed due to weak or missing encryption.
- Example: passwords stored in plain text or with MD5; a site served over plain HTTP.
- Prevent: HTTPS everywhere; hash passwords with bcrypt, scrypt or Argon2; encrypt sensitive data at rest; never write your own crypto.
A03: Injection
Untrusted input is executed as code or a query: SQL injection, command injection, and cross-site scripting (XSS).
- Example: a search box that builds SQL by joining strings.
- Prevent: parameterised queries; output encoding; validate input. See the detailed SQL injection tutorial.
A04: Insecure Design
The flaw is in the design itself, not the code.
- Example: a password reset that only asks for a date of birth; no rate limit on OTP attempts.
- Prevent: threat-model features before building them; add limits, abuse cases and secure defaults to requirements.
A05: Security Misconfiguration
Unsafe default settings or exposed internals.
- Example: default admin passwords, directory listing enabled, detailed stack traces shown to users, public cloud storage buckets.
- Prevent: hardened, repeatable configurations; remove unused features; review cloud permissions regularly.
A06: Vulnerable and Outdated Components
Using libraries or frameworks with known vulnerabilities.
- Example: an old logging library with a published remote code execution flaw.
- Prevent: keep an inventory of dependencies; run
npm audit, Dependabot, OWASP Dependency-Check or similar; patch promptly.
A07: Identification and Authentication Failures
Weaknesses in login and session handling.
- Example: unlimited login attempts allow password guessing; sessions stay valid after logout or a password change.
- Prevent: rate limiting and lockouts; multi-factor authentication; secure, HttpOnly cookies; invalidate sessions on logout and on password change.
A08: Software and Data Integrity Failures
Trusting code or data without verifying it.
- Example: a CI pipeline that pulls an unpinned script from the internet; insecure deserialization of user data.
- Prevent: sign and verify updates; pin dependencies; protect CI/CD secrets and permissions.
A09: Security Logging and Monitoring Failures
Attacks happen and nobody notices.
- Example: thousands of failed logins with no alert.
- Prevent: log security events (logins, permission changes, admin actions) without logging secrets; alert on anomalies; keep an audit trail.
A10: Server-Side Request Forgery (SSRF)
The server is tricked into requesting internal URLs.
- Example: an "import image from URL" feature fetches
http://169.254.169.254/and leaks cloud credentials. - Prevent: allow-list permitted domains; block internal IP ranges; avoid returning raw responses to the user.
Quick reference
| Risk | One-line defence |
|---|---|
| Broken access control | Check permissions on the server, every time |
| Cryptographic failures | HTTPS + strong password hashing |
| Injection | Parameterised queries, output encoding |
| Insecure design | Threat-model before building |
| Misconfiguration | Hardened defaults, no debug in production |
| Outdated components | Scan and patch dependencies |
| Auth failures | Rate limits, MFA, proper session handling |
| Integrity failures | Pin and verify dependencies and builds |
| Logging failures | Log and alert on security events |
| SSRF | Allow-list outbound requests |
How testers can use this list
Turn each risk into test cases: try accessing other users' records by changing IDs, submit special characters in every input, check error pages for stack traces, try 20 wrong passwords, and confirm logout really ends the session. Always test only applications you are authorised to test.
Interview questions
- What is IDOR? Insecure Direct Object Reference: accessing another user's data by changing an identifier, caused by missing server-side authorisation.
- Authentication vs authorisation? Authentication proves who you are; authorisation decides what you may do.
- Stored vs reflected XSS? Stored XSS is saved on the server and served to other users; reflected XSS comes back immediately from a crafted request.
Next steps
Pick one application you built and review it against all ten risks. Learn ethical hacking, SOC operations and AI security hands-on in the Cyber Security + AI course.