OWASP Top 10 Explained with Practical Examples

As a web developer, you've probably heard of the OWASP Top 10—the list of the most critical web application security risks. But do you know how these risks manifest in real code? In this article, we'll walk through each of the OWASP Top 10 (2021 edition) with practical examples and concrete defenses. By the end, you'll be able to spot and fix these vulnerabilities in your own projects.

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: A web app fetches user data via /api/users/123. If there's no check that the logged-in user is 123, an attacker can simply change the ID to access others' data.

Defense: Implement proper authorization checks on every request. Use role-based access control (RBAC) and validate permissions server-side.

2. Cryptographic Failures

This category (previously "Sensitive Data Exposure") covers failures related to cryptography, such as transmitting data in clear text or using weak algorithms.

Example: Storing passwords with MD5 or SHA-1 without salt. Attackers can easily crack these hashes.

Defense: Use strong, adaptive hashing algorithms like bcrypt, scrypt, or Argon2. Always enforce HTTPS.

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 concatenates user input into an SQL query:

SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'

An attacker could enter ' OR '1'='1 to bypass authentication.

Defense: Use parameterized queries or prepared statements. Never concatenate user input into queries.

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, or lacks rate limiting.

Defense: Threat modeling during design, use secure design patterns, and implement rate limiting and account lockout.

5. Security Misconfiguration

This includes default accounts, unused pages, unpatched flaws, unprotected files and directories, and more.

Example: Leaving directory listing enabled on an Nginx server, exposing sensitive files.

Defense: Harden your configurations: disable directory listing, remove default accounts, keep software updated, and use security headers.

6. Vulnerable and Outdated Components

Using components with known vulnerabilities can compromise your entire application.

Example: Using an old version of a JavaScript library like lodash with a known prototype pollution vulnerability.

Defense: Regularly scan dependencies (e.g., with npm audit, OWASP Dependency-Check) and update them.

7. Identification and Authentication Failures

These failures allow attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users' identities.

Example: Allowing weak passwords like "123456" or not implementing multi-factor authentication (MFA).

Defense: Enforce strong password policies, implement MFA, and use secure session management.

8. Software and Data Integrity Failures

This category focuses on making assumptions about software updates, critical data, and CI/CD pipelines without verifying integrity.

Example: Downloading and executing binaries from untrusted sources without checking signatures.

Defense: Use digital signatures, verify checksums, and secure your CI/CD pipeline.

9. Security Logging and Monitoring Failures

Insufficient logging and monitoring allows attackers to persist, pivot, and maintain access.

Example: Not logging failed login attempts, making brute-force attacks undetectable.

Defense: Log security-relevant events, set up alerts for suspicious activities, and regularly review logs.

10. Server-Side Request Forgery (SSRF)

SSRF flaws occur when a web application fetches a remote resource without validating the user-supplied URL.

Example: A webhook feature that fetches a URL provided by the user. An attacker could make the server request internal resources like http://169.254.169.254/latest/meta-data/ on AWS.

Defense: Validate and sanitize URLs, use allowlists, and restrict outbound traffic.

Practical Steps to Mitigate OWASP Top 10

1. Implement access control: Enforce authorization checks on every request, server-side.
2. Use secure cryptography: Hash passwords with bcrypt/Argon2, enforce HTTPS.
3. Prevent injection: Use parameterized queries and escape output.
4. Design securely: Threat model, use secure patterns, and rate limit.
5. Harden configurations: Disable unused features, keep software updated, set security headers.
6. Manage dependencies: Regularly scan and update components.
7. Strengthen authentication: Enforce strong passwords, implement MFA.
8. Verify integrity: Use signatures and secure CI/CD.
9. Log and monitor: Log security events, set up alerts.
10. Prevent SSRF: Validate URLs, use allowlists, restrict outbound traffic.

FAQ

What is the OWASP Top 10?

The OWASP Top 10 is a regularly updated list of the most critical web application security risks, published by the Open Web Application Security Project (OWASP). It serves as a baseline for developers to secure their applications.

How often is the OWASP Top 10 updated?

It is updated approximately every three to four years. The latest version is from 2021, with the previous one from 2017.

Can I rely solely on the OWASP Top 10 for security?

No, it's a starting point. You should also consider other resources like the OWASP Application Security Verification Standard (ASVS) and conduct regular security testing.

Want to quickly analyze your Nginx logs for suspicious activity? Try our Nginx Log Analyzer to identify potential attacks and monitor your web server's security.