The OWASP Top 10, Explained in Plain English

What is OWASP, and why should you care?

OWASP (the Open Worldwide Application Security Project) is a nonprofit that has documented web security risks for over two decades. Its Top 10 is the most widely cited list in application security — a ranking of the categories of mistakes that most often lead to real breaches. Job postings cite it, security tools organize their findings around it, and auditors check against it.

This tutorial walks the current edition — OWASP Top 10:2025 — in plain English. You don't need to be a security engineer. If you build, maintain, or even just evaluate software, knowing these ten by name puts you ahead of most developers.

The ten risks, one at a time

A01:2025 — Broken Access Control

Plain English: the app doesn't properly check who is allowed to do what. Logged in as a normal user but able to open an admin page by typing its URL? Able to see order #1002 by changing "1001" in the address bar? That's broken access control.

It has held the #1 spot because it's everywhere: developers remember to build the lock but forget to check it on every door. The 2025 edition also folds in server-side request forgery (SSRF) — tricking a server into making requests to places it shouldn't reach.

A02:2025 — Security Misconfiguration

Plain English: the software is fine; the settings are not. Default passwords left in place, debug modes on in production, cloud storage buckets set to public, error pages that spill internal details. Misconfiguration jumped from #5 in 2021 to #2 in 2025 — modern apps have so many knobs (cloud, containers, frameworks) that getting them all right is genuinely hard.

A03:2025 — Software Supply Chain Failures

Plain English: your app is only as trustworthy as everything it's built from. Modern projects pull in hundreds of open-source packages, build tools, and services — if any one of them is compromised, your app is too. This is a new category for 2025, expanded from 2021's "vulnerable and outdated components," and it reflects real attacks: poisoned packages on npm and PyPI, compromised build pipelines, malicious updates.

A04:2025 — Cryptographic Failures

Plain English: secrets that weren't kept secret. Passwords stored in plain text, sensitive data sent without encryption, old broken algorithms still in use, encryption keys hardcoded into source code. The result is usually the headline kind of breach: "millions of records exposed."

A05:2025 — Injection

Plain English: the app confuses data with instructions. The classic example is SQL injection — a login form where typing a crafted "username" makes the database run the attacker's command. The fix has been known for decades (treat user input as data, never paste it into commands), yet injection still makes every edition of the list. If you go on to read our AI safety tutorial, you'll notice prompt injection is the same disease in a new body.

A06:2025 — Insecure Design

Plain English: the flaw was in the blueprint, not the construction. A password-reset flow that only asks for easily-Googled security questions is insecure even if the code implementing it is perfect. You can't patch your way out of a bad design — which is why security thinking belongs at the whiteboard stage, not just code review.

A07:2025 — Authentication Failures

Plain English: weaknesses in how the app confirms you are who you say you are. Allowing "password123", no protection against bots trying millions of stolen passwords (credential stuffing), session tokens that never expire. Our companion piece on modern password rules covers what good authentication guidance looks like now.

A08:2025 — Software or Data Integrity Failures

Plain English: trusting code or data without verifying it hasn't been tampered with. Auto-updates that don't check signatures, deserializing data from untrusted sources, CI/CD pipelines anyone can push to. Related to supply chain (A03), but focused on the verification step: did anyone check this is what it claims to be?

A09:2025 — Security Logging and Alerting Failures

Plain English: the burglary happened, and nobody was watching the cameras. Breaches routinely go undetected for months because logins, failures, and strange behavior were never logged — or were logged and never alerted on. Renamed in 2025 from "logging and monitoring" to emphasize alerting: logs nobody reads don't help.

A10:2025 — Mishandling of Exceptional Conditions

Plain English: apps behave badly when things go wrong. Errors that expose stack traces, failures that "fail open" (a crashed security check letting everyone through), edge cases nobody handled. This is a new category for 2025 — a reminder that the unhappy path is part of the product.

How to actually use this list

1. As a learner: you now have the vocabulary. When security news says "supply chain attack," you can place it.
2. As a builder: before shipping, walk the ten as a checklist question each: "Where do I check permissions? What did I leave on default settings? What packages am I trusting?"
3. As an AI user: when you ask an AI assistant to generate code, its output can carry these same flaws. Ask it explicitly: "review this code against the OWASP Top 10:2025."

Check your understanding

1. What's the difference between broken access control (A01) and authentication failures (A07)? (Hint: one is about proving who you are; the other about what you're allowed to do afterward.)
2. Why can't insecure design (A06) be fixed with a code patch?
3. Which two categories are new in the 2025 edition?

Key takeaways

• The OWASP Top 10 is the shared vocabulary of web security — the 2025 edition is current.
• Access control mistakes are the #1 risk; misconfiguration and supply chain failures round out the top three.
• Most of these risks are old ideas in new clothes: check permissions, verify what you trust, keep data separate from instructions, watch the logs.

Sources

• OWASP Top 10:2025 — owasp.org/Top10 (primary source; category names and rankings verified July 2026)