OWASP Top 10 Explained in Plain English

If you build, buy or manage web software, you’ve probably seen “OWASP Top 10” in a security questionnaire, a pen test report or a client contract. It’s one of the most quoted lists in security, yet the official write-ups are dense with CWE numbers and jargon.

This guide translates it. For each of the 10 risks, you’ll get a plain-English explanation, a simple example of how it goes wrong, and the fix developers should apply. You’ll also see what changed in the 2025 edition and how to use the list without treating it as a box-ticking exercise.

What the OWASP Top 10 is

OWASP, the Open Worldwide Application Security Project, is a nonprofit foundation that produces free, open security resources. The Top 10 is its awareness document for web application security: a ranked list of the risk categories that cause the most damage.

The 2025 edition is the latest, following the 2021 list. It was presented in November 2025. According to OWASP, it was built from data on more than 2.8 million applications, combined with a community survey of practitioners. The 10 categories cover 248 CWEs (Common Weakness Enumeration entries), which are standardized names for specific coding and design flaws.

2 things to keep in mind:

• It’s a starting point, not a standard. OWASP itself points teams that need a testable requirements list to its Application Security Verification Standard (ASVS).
• It’s about categories, not individual bugs. “Injection” covers SQL injection, command injection, cross-site scripting and more.

The OWASP Top 10:2025 at a glance

The 10 risks, one by one

A01: Broken Access Control

What it is: The app doesn’t properly enforce who can do what. Example: You’re logged in as customer 1001 and view your invoice at /invoices/1001. You change the URL to /invoices/1002 and see someone else’s invoice. Fix: Check authorization on the server for every request, deny by default, and tie records to the logged-in user rather than trusting IDs from the browser. In 2025, OWASP folded server-side request forgery (SSRF), where an attacker tricks your server into calling internal systems, into this category.

A02: Security Misconfiguration

What it is: The software is fine, but it’s set up unsafely. Example: A cloud storage bucket is left public, an admin console uses a default password, or production shows full error stack traces. This category rose from 5th place in 2021 to 2nd in 2025. Fix: Use hardened templates and infrastructure as code so every environment is configured the same way, remove unused features, and review settings regularly. Our cloud security checklist covers the cloud side.

A03: Software Supply Chain Failures

What it is: A new category that expands 2021’s “Vulnerable and Outdated Components.” It covers risks from third-party libraries, build systems and distribution. Example: Your app uses an open-source package that gets hijacked, and the malicious version ships to every customer on your next build. Fix: Keep a software bill of materials (SBOM), scan and update dependencies, pin versions, and protect your CI/CD pipeline with strong access controls. See what a supply chain attack is for real-world patterns.

A04: Cryptographic Failures

What it is: Sensitive data isn’t protected properly. Example: Passwords stored with a fast, unsalted hash, or customer data sent over plain HTTP. Fix: Encrypt data in transit with TLS, encrypt sensitive data at rest, hash passwords with a slow algorithm built for the job (such as bcrypt, scrypt or Argon2), and never write your own crypto.

A05: Injection

What it is: The app mixes untrusted input into a query or command. Example: A login form builds SQL like "SELECT * FROM users WHERE name = '" + input + "'", so an attacker types a crafted value and bypasses the check. Cross-site scripting (XSS) also lives here. Fix: Use parameterized queries or a safe ORM, encode output for the context (HTML, JavaScript, URL), and validate input against an allowlist.

A06: Insecure Design

What it is: The flaw is in the plan, not the code. Example: A password reset flow that relies on easily guessed security questions, or a checkout that lets users change the price in a hidden field. Fix: Threat model new features before building them, use proven design patterns, and write abuse cases alongside user stories.

A07: Authentication Failures

What it is: Weak handling of logins, sessions and credentials. Example: No limit on login attempts, so attackers try millions of leaked passwords (credential stuffing). Fix: Offer multi-factor authentication or passkeys, rate-limit and monitor login attempts, check passwords against known breached lists, and invalidate sessions properly on logout.

A08: Software or Data Integrity Failures

What it is: The app trusts code or data without verifying it. Example: An auto-update feature downloads new code over an unverified channel, or the app deserializes untrusted data that can trigger code execution. Fix: Verify digital signatures on updates and packages, use integrity checks, and avoid deserializing untrusted input.

A09: Security Logging and Alerting Failures

What it is: Attacks happen and nobody notices. OWASP renamed this from “Monitoring” to “Alerting” to stress that logs are useless if no one acts on them. Example: Thousands of failed logins hit an admin account over a weekend, but nothing alerts the team. Fix: Log authentication events, access-control failures and input validation errors, protect the logs, and send high-risk events to a SIEM or alerting tool that someone watches.

A10: Mishandling of Exceptional Conditions

What it is: A new 2025 category about what happens when things go wrong. Example: A payment service times out and the app “fails open,” marking the order as paid. Or an unexpected error leaks database details. Fix: Fail closed by default, handle errors in one consistent place, return generic messages to users, and test edge cases such as timeouts, null values and resource exhaustion.

Key takeaway: Broken access control has been the top risk since 2021. If you fix only one thing, make sure every request is authorized on the server, not just hidden in the interface.

What changed from 2021 to 2025

According to OWASP’s introduction to the 2025 edition:

• 2 new categories: Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10).
• 1 merger: SSRF moved into Broken Access Control.
• 2 renames: “Identification and Authentication Failures” became “Authentication Failures,” and “Security Logging and Monitoring Failures” became “Security Logging and Alerting Failures.”
• Big moves: Security Misconfiguration climbed from 5th to 2nd. Cryptographic Failures dropped from 2nd to 4th, and Injection from 3rd to 5th.

The rise of misconfiguration and supply chain risks reflects how much modern apps depend on cloud settings and third-party code.

How to use the OWASP Top 10 in practice

The list is most useful when it becomes part of how your team builds software, not a document you read once.

1. Train developers on it. Walk through each category with examples from your own stack. Pair it with the free OWASP Cheat Sheet Series for language-specific fixes.
2. Add it to code review. Use the table above as a review checklist, with special attention to authorization checks and input handling.
3. Automate what you can. Add static analysis (SAST), dependency scanning and secret scanning to your CI pipeline. This is the heart of DevSecOps.
4. Test it. Run dynamic scans against staging, and bring in a penetration tester for high-risk apps. Our guide to vulnerability scans vs penetration tests explains which you need.
5. Graduate to ASVS. When you need specific, testable requirements, for example for a client contract, map your controls to OWASP ASVS.
6. Check AI-generated code. AI coding assistants can reproduce the same flaws, especially injection and missing authorization checks. Review their output with the same checklist.

If your app uses large language models, OWASP also publishes a separate Top 10 for LLM applications covering risks like prompt injection.

Where to start this month

For a small team, a realistic first month looks like this:

• Week 1: Audit authorization. List every endpoint and confirm each one checks permissions on the server.
• Week 2: Turn on dependency scanning and update anything with known critical vulnerabilities.
• Week 3: Review production configuration: error messages, default accounts, public storage and security headers.
• Week 4: Confirm that login failures, permission denials and admin actions are logged and that alerts go to a person.

Add a line to your pre-launch QA checklist so new features get the same treatment.

Conclusion

The OWASP Top 10 is a short, practical map of where web apps break. The 2025 edition keeps broken access control at the top, highlights how much risk now comes from configuration and supply chains, and adds a new focus on handling errors safely. Use it to train your team, guide code review and prioritize testing, and treat it as the floor for application security, not the ceiling.

Sources

• OWASP Top 10:2025 — the current list of 10 categories, A01 through A10
• OWASP Top 10:2025 Introduction — what changed from 2021, methodology, 248 CWEs and data from 2.8 million applications
• OWASP Application Security Verification Standard — testable requirements for teams that need a standard
• OWASP Cheat Sheet Series — practical, language-specific remediation guidance