OWASP Top 10 explained for non-security devs
The OWASP Top 10 is a list of the most common web app vulnerabilities. It gets updated every few years. Security tools love to say they check for it. Here's what it actually means in plain terms.
1. Broken access control
Users can do things they shouldn't. Editing other people's profiles, accessing admin pages without being an admin, downloading files that don't belong to them. Usually happens when you check permissions on the frontend but forget to check on the backend.
2. Cryptographic failures
Sensitive data stored or transmitted without proper encryption. Passwords in plain text. Credit card numbers in a database column with no encryption. HTTP instead of HTTPS.
3. Injection
Sending malicious data that your app executes as code. SQL injection is the classic version. You build a query by concatenating user input, someone sends '; DROP TABLE users; --, and now you have a problem. Use parameterized queries.
4. Insecure design
Security problems baked into the architecture itself. A password reset flow that doesn't expire tokens. An admin feature accessible by changing a URL parameter. These are harder to fix because they require redesign, not just a patch.
5. Security misconfiguration
Default credentials left unchanged. Debug mode on in production. Error messages that leak stack traces. S3 buckets set to public.
6. Vulnerable components
npm packages with known exploits that you haven't updated. This is why npm audit exists.
7. Authentication failures
Weak passwords allowed. No rate limiting on login attempts. Sessions that don't expire. JWT tokens verified incorrectly.
8. Software integrity failures
Running code from sources you haven't verified. CDN scripts that could be compromised. Auto-updating dependencies without checking changelogs.
9. Logging failures
No record of who did what, when. If something goes wrong, you have no way to figure out what happened.
10. Server-side request forgery
Your server fetches a URL based on user input. Someone passes http://169.254.169.254/ (AWS metadata endpoint) instead. Your server helpfully fetches it and returns the credentials.