Preview

OWASP Top 10 Explained: What Every Developer Needs to Know

I've had conversations with developers who have been writing production code for years and have never heard of the OWASP Top 10. That's not a criticism — it's a gap in how we teach software development. Security is still treated as someone else's job. But in 2024, that assumption is how breaches happen.

This post is for developers. Not security professionals — developers. I'm going to walk through the OWASP Top 10 in plain language, show you what each vulnerability looks like in real code, and tell you exactly how to prevent it.

What is OWASP?

The Open Web Application Security Project (OWASP) is a nonprofit foundation that publishes freely available security resources. Their Top 10 list represents the ten most critical web application security risks, compiled from data contributed by hundreds of organizations and security researchers worldwide. It's updated every few years to reflect the evolving threat landscape.

Understanding this list is baseline knowledge for anyone writing web applications.

1. Broken Access Control

What it is: Users can access resources or actions they shouldn't be able to. This includes accessing other users' data, performing admin actions without authorization, or bypassing API access controls.

Real example: A URL like /user/profile?id=1001 shows user 1001's profile. If changing the ID to 1002 shows someone else's profile — that's broken access control. No authentication check on the server side.

Prevention: Enforce access control on the server, not the client. Use deny-by-default policies — if access isn't explicitly granted, it's denied. Never trust client-supplied IDs to control what data is returned.

2. Cryptographic Failures

What it is: Sensitive data (passwords, credit card numbers, health records) is transmitted or stored without adequate encryption, or with weak algorithms.

Real example: Storing passwords in plaintext in a database. Transmitting sensitive data over HTTP instead of HTTPS. Using MD5 or SHA-1 for password hashing (both are crackable).

Prevention: Use bcrypt, Argon2, or scrypt for passwords. Use TLS 1.2+ for all data in transit. Classify your data and apply appropriate protection based on sensitivity. Don't roll your own cryptography.

3. Injection

What it is: Untrusted data is sent to an interpreter as part of a command or query. SQL injection is the most common form, but this also includes NoSQL injection, OS command injection, and LDAP injection.

Real example:

query = "SELECT * FROM users WHERE username = '" + username + "'"

If username is ' OR '1'='1, this query returns all users in the database.

Prevention: Use parameterized queries (prepared statements). Never concatenate user input into queries. Validate and sanitize all inputs. I implemented this in my internship at Sonata Software — parameterized queries reduced our SQL injection surface to zero.

4. Insecure Design

What it is: Vulnerabilities that result from missing or ineffective security controls at the design level — not just implementation bugs, but fundamental architectural flaws.

Real example: A password reset feature that emails a reset link but doesn't expire it, doesn't tie it to the original requesting device, and allows unlimited reset attempts. Any attacker who intercepts one email can take over any account indefinitely.

Prevention: Use threat modeling during design. Ask "what could go wrong here?" before writing code. Reference secure design patterns. Build security into requirements, not as an afterthought.

5. Security Misconfiguration

What it is: Default configurations left unchanged, unnecessary features enabled, unpatched software, error messages that expose internal system details.

Real example: A cloud storage bucket (S3, Azure Blob) configured with public read access. Default admin credentials on a database or CMS. Stack traces displayed to users when an error occurs.

Prevention: Implement a minimal footprint — disable everything you don't need. Regularly review configurations against CIS benchmarks. Automated configuration scanning (tools like ScoutSuite for cloud) helps catch drift. Store nothing sensitive in error messages returned to users.

6. Vulnerable and Outdated Components

What it is: Using libraries, frameworks, or other software components with known vulnerabilities.

Real example: Using an old version of Log4j (before the Log4Shell patch in December 2021) — a single malicious string in a log message could give an attacker remote code execution. This vulnerability affected thousands of organizations worldwide.

Prevention: Maintain an inventory of your dependencies (software bill of materials). Subscribe to vulnerability feeds (NVD, GitHub Security Advisories). Automate dependency scanning with tools like Dependabot, Snyk, or OWASP Dependency-Check. Update aggressively.

7. Identification and Authentication Failures

What it is: Weaknesses in authentication and session management that allow attackers to impersonate users.

Real example: Sessions that don't expire after logout. Allowing unlimited login attempts (enabling brute force). Not using multi-factor authentication for sensitive operations.

Prevention: Implement multi-factor authentication. Use secure, randomly generated session tokens. Expire sessions after inactivity. Implement account lockout after failed login attempts. Never store session tokens in URLs.

8. Software and Data Integrity Failures

What it is: Code and infrastructure that doesn't protect against integrity violations — including insecure CI/CD pipelines, deserialization of untrusted data, and auto-updates without verification.

Real example: A build pipeline that pulls dependencies from an untrusted registry. Deserializing a user-supplied object without validating its contents first. The SolarWinds attack exploited exactly this — a compromised build pipeline.

Prevention: Verify software packages using digital signatures. Implement CI/CD pipeline security controls. Don't deserialize data from untrusted sources. Use integrity checks for software updates.

9. Security Logging and Monitoring Failures

What it is: Insufficient logging means attacks go undetected. Without proper logs, you can't investigate incidents, detect ongoing attacks, or understand your security posture.

Real example: An application that logs nothing when authentication fails repeatedly. No alerts when unusual data volumes are accessed. No way to reconstruct what happened during an incident.

Prevention: Log authentication events (success and failure), access control decisions, and input validation failures. Use a SIEM like Splunk or Wazuh to aggregate and analyze logs. Set up alerts for suspicious patterns — multiple failed logins, large data exports, access at unusual times. This is something I work with directly in my coursework — log analysis is a core security skill.

10. Server-Side Request Forgery (SSRF)

What it is: An attacker tricks the server into making requests to internal resources or external systems on their behalf. This is especially dangerous in cloud environments.

Real example: A feature that fetches a URL provided by the user — https://yourapp.com/fetch?url=http://169.254.169.254/latest/meta-data/ — can be used to access the AWS instance metadata API and steal credentials.

Prevention: Validate and sanitize all user-supplied URLs. Implement allowlists for permitted destinations. Disable HTTP redirects if not needed. Segment internal network access so application servers can't reach sensitive internal resources directly.

Putting It Together

No single vulnerability class exists in isolation. Real-world attacks often chain multiple issues — a misconfiguration exposes an injection point, which is logged inadequately, so the breach goes undetected. Understanding the full Top 10 as an interconnected picture, rather than isolated items on a checklist, is what separates security-conscious developers from the rest.

As a developer, you don't need to become a penetration tester. But you do need to understand how your applications fail. The OWASP Top 10 is your starting point.

If you want to go deeper, I highly recommend OWASP's own documentation (free on their website), and platforms like WebGoat or DVWA where you can practice exploiting and fixing these vulnerabilities in a safe environment.

If you're building web applications and want to do a quick self-assessment, OWASP provides a free application security verification standard (ASVS) checklist. It's an excellent tool for any development team.