OWASP Top 10

The OWASP Top 10 is a ranked list of the most critical web application security vulnerabilities. Understanding these vulnerabilities and how to prevent them is essential for building secure applications. This guide explains each vulnerability in practical terms.

1. Broken Access Control

What it is: Users can access, modify, or delete resources they shouldn't be able to. The app fails to properly check permissions.

Real example: A user edits their profile at /profile/123. An attacker changes the URL to /profile/456 and sees someone else's profile. The app doesn't verify the user owns the profile before showing it.

How to prevent: Always check permissions. Before returning a user's profile, verify the logged-in user is the owner. Use middleware that checks authorization before handlers run. Test by logging in as User A and trying to access User B's data.

2. Cryptographic Failures

What it is: Sensitive data is exposed because encryption is weak, missing, or improperly implemented. Passwords stored in plaintext, unencrypted credit card data, or HTTP transmission.

Real example: A company stores passwords in plaintext. An attacker breaches the database and immediately has all passwords. A user who reused their password is now compromised on other sites.

How to prevent: Hash passwords with bcrypt or Argon2. Encrypt sensitive data at rest (AES-256). Always use HTTPS for transmission. Use TLS 1.2 or higher. Encrypt database backups. Use a secrets management system for API keys.

3. Injection

What it is: Untrusted user input is sent to an interpreter (SQL, template engine, command shell) without proper escaping, allowing the attacker to inject malicious code.

Real example (SQL Injection): A login form takes a username. The code runs: query = "SELECT * FROM users WHERE email = '" + email + "'". An attacker enters admin@example.com' OR '1'='1. The query becomes: SELECT * FROM users WHERE email = 'admin@example.com' OR '1'='1', returning all users.

How to prevent: Use parameterized queries (prepared statements): query("SELECT * FROM users WHERE email = ?", [email]). The database separates code from data, preventing injection. Never concatenate user input into queries or commands.

4. Insecure Design

What it is: The application is designed without security in mind. Missing security controls, no authentication on sensitive operations, or poor threat modeling.

Real example: A password reset flow doesn't verify the user's email—anyone can reset anyone else's password. The design lacks a critical control (email verification).

How to prevent: Design with security in mind from the start. Threat model your application: what could go wrong? Where are sensitive data flows? Add controls to protect them. Follow security principles: least privilege, defense in depth, fail securely. Have a security-focused person review designs before implementation.

5. Security Misconfiguration

What it is: The application is configured insecurely. Default credentials left enabled, unnecessary services running, missing security headers, verbose error messages revealing system details.

Real example: An AWS S3 bucket is accidentally set to public, exposing millions of files. The default admin credentials for a service weren't changed, and an attacker logs in.

How to prevent: Change all default credentials. Disable unnecessary services. Run security scanners (OWASP ZAP, Burp Suite) to check for misconfiguration. Set security headers (CSP, HSTS, etc.). Don't expose stack traces to users; log them securely instead. Use infrastructure-as-code to document and enforce secure configurations.

6. Vulnerable Components

What it is: Your application uses libraries with known vulnerabilities. An attacker exploits the vulnerability in the library to compromise your app.

Real example (Log4Shell): Applications worldwide used the logging library log4j. A critical vulnerability was discovered: sending a specially crafted message could execute arbitrary code. Millions of applications were vulnerable overnight.

How to prevent: Keep dependencies updated. Use tools like Dependabot or Snyk to scan for known vulnerabilities and automatically create PRs to fix them. Monitor CVE databases. Have a process to patch vulnerabilities quickly. Evaluate new dependencies carefully—are they maintained? Do they have a history of security issues?

7. Authentication and Session Management Failures

What it is: Passwords are weak or exposed. Sessions can be guessed or hijacked. Multi-factor authentication is missing.

Real example: A user sets a password "password123." An attacker uses a password dictionary and guesses it. A session ID is predictable (1, 2, 3...), and an attacker guesses another user's session.

How to prevent: Enforce strong passwords using a breach database (HIBP). Hash passwords with bcrypt/Argon2. Rate-limit login attempts. Use randomized, long session IDs. Implement multi-factor authentication. Use secure cookie flags (HttpOnly, Secure, SameSite). Expire sessions appropriately.

8. Software and Data Integrity Failures

What it is: The application trusts untrusted data or code without verification. Downloading and executing software without checking authenticity, or modifying data without integrity checks.

Real example: A package manager downloads a library from an untrusted source without verifying the signature. The library is malicious and steals API keys from all machines that installed it.

How to prevent: Verify the integrity of downloaded software with cryptographic signatures. Use HTTPS and validate certificates. Pin dependencies to specific versions. Review dependency updates before applying them. Use signed artifacts from trusted sources.

9. Logging and Monitoring Failures

What it is: The application doesn't log security events or logs are not monitored. An attacker exploits the app, and there's no record. Detection systems don't alert on suspicious activity.

Real example: An attacker breaks into the admin account and exfiltrates customer data. No one notices for 6 months because failed login attempts aren't logged or monitored.

How to prevent: Log all security events: failed logins, permission denials, data access. Use a centralized logging system (ELK Stack, Datadog). Set up alerts for suspicious patterns (many failed logins, unusual data access). Monitor logs regularly. Keep logs secure and immutable (separate from the application).

10. Server-Side Request Forgery (SSRF)

What it is: The application makes requests to URLs based on user input without validation. An attacker tricks the server into requesting internal or restricted resources.

Real example: A website has a feature to download files by URL. A user enters http://localhost:8080/admin. The server makes the request, exposing the internal admin panel.

How to prevent: Validate and whitelist URLs. Don't allow requests to localhost or private IP ranges. Use a URL parser to ensure the host is what you expect. For file downloads, host files yourself rather than proxying user-provided URLs. Disable HTTP redirects or validate redirects carefully.

Additional Vulnerabilities Beyond the Top 10

The Top 10 are the most critical, but other vulnerabilities matter:

Cross-Site Scripting (XSS): Untrusted input is rendered in HTML. An attacker injects JavaScript that runs in other users' browsers.

Cross-Site Request Forgery (CSRF): An attacker tricks a user into making unwanted requests (e.g., transferring money) by visiting a malicious site.

Clickjacking: An attacker overlays a transparent button over your site, tricking users into clicking it unknowingly.

Security as a Practice

The OWASP Top 10 aren't academic—they're the vulnerabilities that actually compromise real applications. Every one is preventable with proper design, implementation, and testing. Start by understanding these 10, implement defenses against them, and continually improve your security posture. Make security a habit, not an afterthought.