OWASP Top Ten for Software Developers

Early in my career, I thought security was someone else's job. The security team runs scans, finds issues, we fix them. Then I shipped a feature with a broken access control flaw that let any authenticated user view any other user's data. A simple IDOR. It took 20 minutes to exploit, and it was live for three weeks.

That is when I started studying the OWASP Top Ten.

What is OWASP?

OWASP stands for Open Web Application Security Project. It is a community-driven organization that publishes tools, guides, and research on application security. Their most well-known output is the Top Ten: a ranked list of the most critical security risks in web applications.

The list is updated every few years based on real-world data from thousands of applications. It is not theoretical. It reflects what actually gets exploited.

Why it matters for developers

Security is not a feature you bolt on after deployment. It is a property of how you write code. The OWASP Top Ten gives you a mental checklist. Before I merge a PR, I ask: does this introduce any of these risks?

It also helps with prioritization. You cannot fix everything. The Top Ten tells you where the highest-impact vulnerabilities are.

The ten risks

1. Injection. Untrusted data gets sent to an interpreter as part of a command. SQL injection is the classic example, but it applies to NoSQL, LDAP, OS commands, and ORM queries too. Fix: parameterized queries, never string concatenation.

2. Broken Authentication. Weak passwords allowed. Session tokens exposed in URLs. No brute-force protection. No multi-factor auth. Any of these gives attackers a way in. Fix: use proven auth libraries, enforce strong passwords, implement MFA, expire sessions aggressively.

3. Sensitive Data Exposure. Data stored or transmitted without encryption. Passwords hashed with MD5. API responses leaking fields that should be internal. Fix: encrypt at rest and in transit. Use bcrypt or argon2 for passwords. Audit your API responses.

4. XML External Entities (XXE). If your application parses XML, an attacker can include references to external entities that read local files, trigger SSRF, or cause denial of service. Fix: disable external entity processing in your XML parser. Better yet, use JSON.

5. Broken Access Control. The most common flaw I see in production code. User A can access User B's data by changing an ID in the URL. Admin endpoints accessible to regular users. Fix: enforce authorization on every request, server-side. Never rely on the client to restrict access.

6. Security Misconfiguration. Default credentials left in place. Unnecessary services running. Stack traces exposed in error responses. Debug mode enabled in production. Fix: automate your configuration. Use infrastructure as code. Audit defaults.

7. Cross-Site Scripting (XSS). Attacker injects JavaScript that runs in other users' browsers. Steals sessions, redirects users, defaces pages. Fix: escape output, sanitize input, use Content Security Policy headers. Frameworks like React escape by default, but dangerouslySetInnerHTML bypasses that.

8. Insecure Deserialization. Accepting serialized objects from untrusted sources without validation. Attackers craft payloads that execute arbitrary code when deserialized. Fix: do not deserialize untrusted data. If you must, validate the structure strictly before processing.

9. Using Components with Known Vulnerabilities. Every dependency is an attack surface. An outdated library with a published CVE is an open door. Fix: run npm audit regularly. Use Dependabot or Renovate. Pin versions and review updates.

10. Insufficient Logging and Monitoring. If you cannot detect an attack, you cannot respond to it. Most breaches are discovered weeks or months later, often by external parties. Fix: log authentication events, access control failures, and input validation errors. Set up alerts. Have an incident response plan.

How I use this list

I do not memorize it. I reference it during code reviews and design discussions. When someone proposes a new API endpoint, I mentally run through the list. Does this accept user input? How is access controlled? What gets logged?

The list is not exhaustive. It is a starting point. But covering these ten risks puts you ahead of most teams.