OWASP Top 10 explained for founders and engineers

Every security questionnaire eventually asks: "are you compliant with the OWASP Top 10?" The honest answer for most teams is "mostly, we think." Here is what the list actually is, what each item means in plain language, and the three that cause the most real-world damage.

What the OWASP Top 10 actually is

The Open Worldwide Application Security Project publishes the Top 10 every few years. It is not a standard or a law. It is a awareness document: the ten categories of web application security risk that show up most often in real applications, based on data contributed by organizations worldwide. The 2025 edition refined the categories again, and the current list runs: broken access control, cryptographic failures, injection, insecure design, security misconfiguration, vulnerable and outdated components, authentication failures, software and data integrity failures, logging and monitoring failures, and server-side request forgery.

The three that actually break companies

1. Broken access control (OWASP A01)

Access control means user A cannot see user B's data. It breaks quietly: an API endpoint that trusts the ID in the URL, an admin route hidden from the menu but not from the router, a "temporary" bypass shipped to production. Scanners routinely rate these findings low because they cannot tell whether object 1042 belongs to you. A human tester changes one number and reads someone else's payroll. This category has topped the list for years and deservedly so.

2. Injection, still alive (A03)

SQL injection stopped being news a decade ago and never actually left. It survives in report queries, export features, legacy internal tools, and anywhere a string gets concatenated because the ORM made the easy path hard. Parameterized queries kill it. So does a code review that looks for the pattern once a quarter.

3. Insecure design (A04)

The newest and most uncomfortable category: the vulnerability was not a bug, it was the plan. Password reset that emails a new password in plaintext. A refund flow that trusts a client-side total. You cannot patch a design flaw; you redesign it. This is exactly why threat modeling before building beats scanning after shipping.

The rest, one line each

• Cryptographic failures: passwords hashed with MD5, tokens over HTTP, keys in the repository
• Security misconfiguration: debug mode on, S3 buckets public, default credentials untouched
• Vulnerable components: the 2019 dependency nobody updated because the build broke
• Authentication failures: no rate limiting, session tokens that never expire, MFA that can be skipped
• Integrity failures: auto-updates without signature checks, CI pipelines that trust any commit
• Logging failures: breaches discovered eight months late because nobody was watching
• SSRF: your server happily fetches http://169.254.169.254 and hands over cloud credentials

Compliance questionnaires ask about the Top 10. Attackers only care about the one you missed.

How to actually cover the list

Run a vulnerability assessment continuously for the component and configuration categories. Run a manual penetration test annually for access control, business logic and design. And read the list once a year with your engineering leads, asking one question per item: where in our codebase could this exist? If nobody knows, that is the finding.

Want a second pair of eyes on your top three risks? Book a free scope call with our researchers.