OWASP & Standards

OWASP Top 10, Explained for Working Developers

The OWASP Top 10 gets cited constantly in security tooling, but most of it reads like a compliance checklist. Here's what each category actually means for the code you write day to day.

F Fora AI Team July 10, 2026 9 min read

If you've used any security scanner — including this one — you've seen issues tagged with things like "A03:2021" or "A07:2021." These reference numbers come from the OWASP Top 10, a list maintained by the Open Web Application Security Project that gets updated every few years based on real-world breach data. It's useful, but the official descriptions are written for security teams, not for someone shipping a feature on a Tuesday. Here's a translation.

A01: Broken Access Control

This is the most common category in the current list, and it's rarely a single bug — it's usually a missing check. A user can view another user's invoice by changing an ID in the URL. An API endpoint checks that you're logged in but not that you own the resource you're requesting. If your authorization logic is "are they logged in?" instead of "are they allowed to do this specific thing?", you have this problem somewhere.

A02: Cryptographic Failures

This used to be called "Sensitive Data Exposure," and the rename is more accurate: it's about how data is protected, not just whether it leaks. Storing passwords with MD5 or SHA-1 instead of a purpose-built algorithm like Argon2 or bcrypt falls here. So does transmitting anything sensitive over plain HTTP, or generating a password-reset token with random.random() instead of the secrets module.

A03: Injection

SQL injection is the famous example, but the category covers any place untrusted input changes the meaning of a command — command injection through os.system(), template injection through unescaped output, LDAP injection, and so on. The common thread is treating user input as code instead of data.

A04: Insecure Design

This one is newer and broader than the others — it's not a specific bug pattern but a category for flaws baked into how a feature was designed in the first place. A checkout flow that trusts a client-supplied price. A password-reset flow with no rate limiting. These aren't fixed by a patch; they need the feature rethought.

A05: Security Misconfiguration

Default credentials left in place. DEBUG=True in production, quietly leaking stack traces and settings values to anyone who triggers a 500 error. Missing security headers. This category is unglamorous but accounts for a huge share of real incidents, because it's easy to get right in development and forget to lock down before shipping.

A06: Vulnerable and Outdated Components

Every dependency you install is code you didn't write running with your application's permissions. A known CVE in an old version of a package you haven't updated in two years is functionally the same as writing the vulnerability yourself.

A07: Identification and Authentication Failures

Weak password policies, session tokens that don't expire, login endpoints with no rate limiting that allow unlimited password guesses. This is the category behind most account-takeover incidents.

A08: Software and Data Integrity Failures

This covers things like insecure deserialization — unpickling data from a source you don't fully trust, which in Python can execute arbitrary code as a side effect of just loading the data. It also covers CI/CD pipelines that pull unverified dependencies or update packages automatically without any integrity check.

A09: Security Logging and Monitoring Failures

If a breach happens and nobody notices for six months because nothing was logged, the breach itself often becomes the smaller problem. This category is about having enough visibility to detect and respond to an incident quickly.

A10: Server-Side Request Forgery (SSRF)

If your server fetches a URL on behalf of a user — to generate a thumbnail, follow a webhook, or check a link — and that URL isn't validated, an attacker can point it at your internal network. This has been used repeatedly to reach cloud metadata endpoints and steal credentials.

Why this list matters for tooling

Every issue Fora AI's scanner surfaces is mapped back to one of these categories, partly so the report is useful to a security-minded reader, and partly because the mapping forces some discipline on what counts as a real, cited finding rather than a vague warning.

← Back to all posts