The OWASP Top 10, Explained for Business Leaders

Most breaches don't involve exotic techniques. They exploit the same handful of application weaknesses that the Open Web Application Security Project has been cataloguing for two decades. Here's what the list means if you're accountable for the risk but don't write the code.

The risks, in business terms

• Broken access control — users can reach data or actions that aren't theirs. The most common serious finding, and the one behind most "customer saw another customer's data" incidents.
• Cryptographic failures — sensitive data stored or transmitted without proper encryption. Directly triggers breach-notification obligations.
• Injection — untrusted input is executed as a command, letting an attacker read or modify your database.
• Insecure design — the flaw is in the plan, not the code; no amount of careful implementation fixes a missing rate limit on password reset.
• Security misconfiguration — default credentials, verbose errors, an open storage bucket. Cheap to prevent, common in practice.
• Vulnerable and outdated components — a known flaw in a library you depend on. Automated scanners find these first, and so do attackers.
• Identification and authentication failures — weak passwords, no MFA, sessions that never expire.
• Software and data integrity failures — trusting an unverified update or build artifact; the supply-chain risk.
• Security logging and monitoring failures — the reason breaches are discovered months later by a third party.
• Server-side request forgery — the application is tricked into fetching internal resources on an attacker's behalf.

One question to ask per risk

• Access control: "Show me how we test that user A cannot read user B's data."
• Dependencies: "What's our process when a critical CVE is published for a library we use?"
• Configuration: "When did we last review production settings against a hardening baseline?"
• Authentication: "Is MFA enforced on admin and production access, and how quickly do sessions expire?"
• Monitoring: "If someone brute-forced a login tonight, who would know, and when?"

Making it routine rather than heroic

• Automated dependency scanning in CI, with a policy for how fast criticals get patched.
• Static analysis on every pull request — cheap, and catches injection and secret-leak patterns.
• A threat-model conversation at design time for anything touching money, identity, or regulated data.
• An independent penetration test before major launches, and annually thereafter.
• Centralized logging with alerting on authentication anomalies.