Look, I get it. Someone mentions OWASP in a meeting and you nod like you totally remember what each item means. Then you go back to your desk and it's straight back to feature work. Security can wait, right? Except it can't. Not really. I spent three years ignoring this stuff until a penetration tester absolutely wrecked an application I'd built. Humbling doesn't begin to cover it. So here's what I wish someone had explained to me back then. Quick Context OWASP stands for Open Web Application Security Project. They're a nonprofit that publishes this Top 10 list based on actual breach data from real companies. Not theoretical attacks, actual ones that worked. The list changes every few years. Things move up, move down, get combined. The current version reflects what's actually hurting organizations right now. 1. Broken Access Control This one's at the top for a reason. It's embarrassingly common. Picture this: your app has a URL like /api/orders/5291 that shows order details. What happens if someone changes that to /api/orders/5292? If they see another customer's order, congratulations, you have broken access control. /api/orders/5291 /api/orders/5292 I've seen this in production apps from companies that should know better. The fix isn't complicated, check permissions on every single request. Deny by default. But somehow it keeps slipping through. 2. Cryptographic Failures Used to be called "Sensitive Data Exposure" which honestly made more sense to most people. This is all the crypto mistakes. Sending data over HTTP instead of HTTPS. Storing passwords with MD5 (please stop doing this). Hardcoding API keys. Using encryption algorithms from 2005. One time I found a codebase storing credit card numbers in plaintext in a comments field. The developer thought nobody would look there. Attackers always look there. 3. Injection The classic. SQL injection has been around forever and we're still finding it everywhere. You know those login forms? If entering ' OR '1'='1 as a password lets you in, that's injection. Your code is mixing user input with commands, and attackers exploit that gap. ' OR '1'='1 Parameterized queries fix this. Every modern framework supports them. There's really no excuse anymore, yet here we are in 2024 still talking about it. 4. Insecure Design This one's tricky because it's not about bugs in your code. It's about flaws in your thinking. Say you build a password reset feature that asks security questions. Seems reasonable. Except those answers are often on someone's Facebook profile. Your mom's maiden name? Probably tagged in photos. First pet? Posted about it for years. The implementation might be flawless. The design itself is the problem. That's why threat modeling matters before you write a single line. 5. Security Misconfiguration Oh boy. This is the one that keeps security teams up at night. Default admin passwords left unchanged. Debug mode enabled in production. S3 buckets set to public because someone was testing something. Error messages that dump stack traces to users. Cloud infrastructure made this worse, honestly. So many settings, so many ways to mess up. I've lost count of the "Company X Exposes Millions of Records" headlines that trace back to a checkbox someone forgot to uncheck. 6. Vulnerable and Outdated Components Remember Log4Shell? That logging library nobody thought twice about suddenly became the biggest vulnerability in years. Millions of applications affected overnight. Your app isn't just your code. It's every dependency, every library, every framework version. That npm package you installed two years ago and forgot about? Check if it has known vulnerabilities. Spoiler: it probably does. Keep an inventory. Update regularly. Remove stuff you're not using. Boring advice, but it works. 7. Identification and Authentication Failures Passwords are hard. People pick bad ones, reuse them across sites, write them on sticky notes. And that's just the user side. On the application side, there's session management to screw up. Token expiration. Credential stuffing protection. What happens after too many failed logins? I worked on an app once that didn't invalidate sessions after password changes. So if someone's account got compromised and they changed their password, the attacker's session still worked. Fun times. 8. Software and Data Integrity Failures This one gained prominence after SolarWinds. Remember that mess? Attackers compromised the build pipeline and pushed malicious updates to thousands of organizations. The updates were signed and everything, they just happened to contain backdoors. When your app auto-updates, how do you know that update is legit? When you pull a Docker image, are you verifying it? When code gets merged, who reviewed it? Supply chain attacks are having a moment right now. Your code might be perfect, but what about everything it depends on? 9. Security Logging and Monitoring Failures Here's a fun statistic: the average time to detect a breach is measured in months, not days. Attackers get in, look around, establish persistence, exfiltrate data, and nobody notices until much later. Why? Because logging is treated as an afterthought. Nobody's watching. Alerts fire so often they get ignored. If someone tries fifty different passwords on an account, does anyone know? If an admin account logs in from a new country at 3 AM, does that trigger anything? Usually not. 10. Server-Side Request Forgery SSRF is newer to the list but it's nasty, especially in cloud environments. Your app has a feature that fetches a URL, maybe for previews or webhooks or whatever. An attacker supplies a URL pointing to internal services. Suddenly your server is making requests to things it shouldn't be able to reach. On AWS, hitting http://169.254.169.254/ gets you instance metadata, potentially including credentials. From outside, that endpoint is unreachable. But if your server makes the request? Different story. http://169.254.169.254/ http://169.254.169.254/ Validate URLs aggressively. Allowlists are better than blocklists here. What Actually Matters You're not going to fix everything tomorrow. That's fine. Start somewhere. Pick the items most relevant to your stack. Run a scanner, but remember automated tools miss context. Get a second pair of eyes on authentication flows. Check your dependency versions. Perfect security is a myth anyway. The goal is being harder to attack than the next target. Attackers, like everyone else, take the path of least resistance. The OWASP Cheat Sheet Series is genuinely useful and free. Bookmark it. Actually read it. Future you dealing with an incident will be grateful. The OWASP Cheat Sheet Series is genuinely useful and free. Bookmark it. Actually read it. Future you dealing with an incident will be grateful.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

This story will praise and/or roast a product, company, service, game, or anything else people like to review on the Internet.

OWASP Top 10: The Security Stuff You Keep Meaning to Learn

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Ransomware Doesn't Need to Lock Your Files Anymore — Here's Why That's Terrifying

Dotting the I's and Crossing the T's of OWASP Top 10 for Mobile Devs (Part 1)

How to Address Bugs, Security, & Reliability: AI for Web Devs

API Architecture: Components and Best Practices

Application Security: A Primer

AppSec Part II: Exploring Advanced Security Models and Architectures for DevSecOps

Ransomware Doesn't Need to Lock Your Files Anymore — Here's Why That's Terrifying

Dotting the I's and Crossing the T's of OWASP Top 10 for Mobile Devs (Part 1)

How to Address Bugs, Security, & Reliability: AI for Web Devs

API Architecture: Components and Best Practices

Application Security: A Primer

AppSec Part II: Exploring Advanced Security Models and Architectures for DevSecOps

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps