OWASP Top 10 Explained with Practical Examples
Every year, thousands of web applications are breached due to the same recurring security flaws. The OWASP Top 10 is a standard awareness document that lists the most critical security risks to web applications. In this article, we’ll walk through each risk, show a practical example, and explain how to mitigate it. Whether you’re a developer, DevOps engineer, or security enthusiast, understanding these risks is essential for building secure systems.
1. Broken Access Control
Broken access control occurs when users can act outside their intended permissions. For example, a user might access another user’s data by changing a URL parameter.
Example: An application uses /api/user/123 to fetch user data. If there’s no check that the logged-in user is indeed user 123, an attacker can change the ID to /api/user/124 and view someone else’s profile.
Mitigation: Implement server-side access control checks. Deny by default. Use role-based access control (RBAC) and validate permissions on every request.
2. Cryptographic Failures
Formerly known as “Sensitive Data Exposure,” this risk involves failing to protect sensitive data in transit or at rest.
Example: Storing passwords in plain text or using weak hashing algorithms like MD5.
Mitigation: Use strong encryption (e.g., AES-256) for data at rest, TLS 1.2+ for data in transit, and strong password hashing (bcrypt, Argon2).
3. Injection
Injection flaws, such as SQL, NoSQL, OS, and LDAP injection, occur when untrusted data is sent to an interpreter as part of a command or query.
Example: A login form that constructs an SQL query like:
SELECT * FROM users WHERE username = '$username' AND password = '$password';If an attacker enters ' OR '1'='1 as username, they can bypass authentication.
Mitigation: Use parameterized queries or prepared statements. Escape special characters and validate input.
4. Insecure Design
Insecure design refers to flaws in the architecture and design of an application, not just implementation bugs.
Example: A password reset feature that uses security questions with easily guessable answers.
Mitigation: Threat modeling during design, secure design patterns, and reference architectures.
5. Security Misconfiguration
This includes default accounts, unused pages, unpatched flaws, unprotected files, and directories.
Example: Leaving the default admin credentials on a CMS or exposing directory listings.
Mitigation: Harden configurations, remove unused features, and automate configuration checks.
6. Vulnerable and Outdated Components
Using libraries, frameworks, or software with known vulnerabilities.
Example: Running an old version of a JavaScript library with a known XSS vulnerability.
Mitigation: Regularly update dependencies, use tools like npm audit or OWASP Dependency-Check, and remove unused dependencies.
7. Identification and Authentication Failures
Weaknesses in authentication and session management.
Example: Allowing weak passwords, no rate limiting on login attempts, or exposing session IDs in URLs.
Mitigation: Implement multi-factor authentication, enforce strong password policies, and use secure session management.
8. Software and Data Integrity Failures
Code and infrastructure that do not protect against integrity violations.
Example: Using untrusted CDNs for scripts without Subresource Integrity (SRI).
Mitigation: Use SRI, verify signatures, and ensure CI/CD pipelines are secure.
9. Security Logging and Monitoring Failures
Insufficient logging and monitoring allow attackers to persist undetected.
Example: Not logging failed login attempts, so brute-force attacks go unnoticed.
Mitigation: Log security-relevant events, monitor logs, and set up alerts for suspicious activities.
10. Server-Side Request Forgery (SSRF)
SSRF occurs when an attacker can make the server perform requests to internal resources.
Example: A webhook feature that fetches a URL provided by the user. An attacker could provide http://169.254.169.254/latest/meta-data/ to access cloud metadata.
Mitigation: Validate and sanitize URLs, use allowlists, and restrict outbound traffic.
Comparison Table
| Risk | Example | Mitigation |
|---|---|---|
| Broken Access Control | Access other user's data via IDOR | Server-side permission checks |
| Cryptographic Failures | Storing passwords in plain text | Use strong hashing and TLS |
| Injection | SQL injection via login form | Parameterized queries |
| Insecure Design | Weak password reset questions | Threat modeling |
| Security Misconfiguration | Default admin credentials | Harden configurations |
| Vulnerable Components | Old library with XSS flaw | Regular updates |
| Auth Failures | No rate limiting on login | MFA and rate limiting |
| Integrity Failures | Untrusted CDN scripts | Subresource Integrity |
| Logging Failures | No logs for failed logins | Centralized logging and alerts |
| SSRF | Fetch internal metadata | URL allowlists |
How to Get Started
- Assess: Run automated scanners and manual reviews against the OWASP Top 10.
- Prioritize: Fix the most critical issues first (e.g., injection, broken access control).
- Train: Educate developers on secure coding practices.
- Monitor: Implement logging and alerting for security events.
- Iterate: Regularly update dependencies and re-test.
FAQ
What is the OWASP Top 10?
The OWASP Top 10 is a regularly updated list of the most critical security risks to web applications, published by the Open Web Application Security Project (OWASP).
How often is the OWASP Top 10 updated?
It is updated approximately every three to four years, with the latest version released in 2021. However, OWASP provides ongoing guidance and updates.
Can I rely solely on the OWASP Top 10 for security?
No, it is a starting point. You should also follow other OWASP projects like the Application Security Verification Standard (ASVS) and conduct regular security testing.
To quickly analyze your Nginx logs for signs of attacks like SQL injection or XSS, try our Nginx Log Analyzer. It helps you spot suspicious patterns and secure your web server.