The OWASP Top 10, Explained for Developers Who Want to Ship Safely

OWASP (the Open Worldwide Application Security Project) is a non-profit that studies how web applications actually get broken and publishes what it finds. Every few years it ranks the categories of weakness that cause the most damage. If you learn only one security framework as a developer, learn this one, because it maps almost perfectly onto the code you write every day.

Below is each category translated out of security jargon, with the practical defence that matters most. The goal is not to memorise definitions — it is to recognise the shape of each problem in your own codebase.

1. Broken Access Control

This is now the most common serious flaw on the web. It means a user can reach data or actions that should not be theirs — reading another person's invoice by changing an ID in the URL, or calling an admin-only API because the check only lived in the front-end. The browser is never a security boundary; anyone can edit a request before it reaches your server.

The defence is to enforce authorisation on the server for every request, based on the logged-in identity, not on what the client claims. Ask "who is asking, and are they allowed to touch this exact record?" inside the API handler itself — every single time.

2. Cryptographic Failures

Formerly called "Sensitive Data Exposure". It covers everything from serving pages over plain HTTP to storing passwords in a way that can be reversed. Data that is sensitive in transit (login forms, tokens, personal details) must travel over HTTPS, and data that is sensitive at rest (passwords, secrets) must be hashed or encrypted with modern, well-reviewed algorithms — never home-made ones.

3. Injection

Injection happens when untrusted input is mixed directly into a command that some interpreter runs — a SQL query, a shell command, an HTML template. The classic example is building a database query by gluing a user's input into a string, so that carefully crafted input changes the meaning of the query.

The universal defence is to never build commands by string concatenation. Use parameterised queries (also called prepared statements) so the database treats user input strictly as data, never as code. Modern ORMs do this for you — the danger returns the moment you drop down to raw string queries.

4. Insecure Design

Some vulnerabilities are not coding mistakes; they are missing safeguards in the plan itself. A password reset flow with no rate limit, an account system with no lockout, a checkout that trusts a price sent from the browser — the code can be flawless and the design still be unsafe. The fix is to think about abuse cases while designing a feature, not only the happy path.

5. Security Misconfiguration

Default admin passwords, verbose error pages that leak stack traces, cloud storage buckets left open to the public, debugging features left on in production. These are not bugs in your logic — they are settings. Keep environments locked down by default, remove anything you are not using, and make sure error messages give users a friendly note while the details go only to your logs.

6. Vulnerable and Outdated Components

Almost every app is mostly other people's code — frameworks, libraries, packages. When a vulnerability is found in one of those dependencies, every app using the old version inherits it. Keep dependencies updated, remove ones you no longer use, and let an automated tool warn you when something you depend on has a known advisory.

7. Identification and Authentication Failures

This covers weak login systems: allowing trivially guessable passwords, not protecting against automated guessing, leaking whether an email exists, or handling sessions carelessly. Support long passphrases, add rate limiting and multi-factor authentication, and make sure logging out and session expiry actually invalidate the session on the server.

8. Software and Data Integrity Failures

Trusting code or data without verifying it hasn't been tampered with — pulling in a script from an untrusted source, or an update mechanism that doesn't check signatures. Prefer trusted sources, pin versions, and verify integrity where the platform supports it.

9. Security Logging and Monitoring Failures

If an attack happens and nothing records it, you find out from your users or the news. Log meaningful security events (failed logins, access-control denials, unexpected input), make sure those logs are actually reviewed or alerted on, and never log secrets or full personal data.

10. Server-Side Request Forgery (SSRF)

SSRF tricks your server into making requests it shouldn't — for example, taking a URL from a user and fetching it, letting an attacker reach internal systems that are normally unreachable from outside. Validate and constrain any URL your server will fetch on a user's behalf, and default to a strict allowlist of destinations.

How to actually use this list

You do not need to become a security specialist to benefit from the Top 10. Treat it as a review lens: before you merge a feature, skim the ten categories and ask whether your change touches any of them. Most real breaches trace back to one of these ordinary categories, not to a genius attacker — which means most breaches are preventable with ordinary care.