The OWASP Top 10:2025 Explained: A Security Checklist for Your Web App

“

Meerako — Dallas, TX experts in building secure, compliant, and enterprise-grade software.

A single security breach can end a startup. It can mean millions in fines — especially under HIPAA or financial services regulation — a permanent loss of customer trust, and in the worst cases, the end of the business entirely. In 2026, web application security isn't an add-on or a nice-to-have. It's the non-negotiable foundation everything else gets built on.

The industry-standard reference for this is the OWASP Top 10, and if the list you're working from still says "2021," it's genuinely out of date — OWASP released Top 10:2025 in January 2026, the first update to the list in five years, drawing on analysis of over 175,000 CVEs mapped across 248 CWEs and practitioner surveys from thousands of organizations. The changes are substantial, not cosmetic: two entirely new categories were added, Security Misconfiguration jumped from fifth place to second, and SSRF was folded into Broken Access Control. At Meerako, security isn't an afterthought bolted on before launch — it's built into our development process from day one. This guide breaks down the current OWASP Top 10:2025 in plain terms and explains how we defend against each category.

• What actually changed in the first OWASP Top 10 update since 2021, and why it matters.
• A clear explanation of each current risk category, from access control to exceptional condition handling.
• The concrete development practices that defend against each one.
• How to think about security maturity as your application scales.

Before the category-by-category breakdown, it's worth understanding what actually moved and why, since a team still defending against the 2021 list has real, concrete gaps in coverage that a five-year-old checklist simply can't account for. Security Misconfiguration climbed from fifth to second place, reflecting how much cloud infrastructure misconfiguration has driven real-world breaches in recent years. A genuinely new category, Software Supply Chain Failures, debuted at third place, expanding well beyond the old "vulnerable and outdated components" framing to cover the entire supply chain — dependencies, build systems, and distribution infrastructure, reflecting the industry's growing concern about compromised packages and build pipelines. And SSRF was absorbed into Broken Access Control rather than remaining a standalone category, while a new category, Mishandling of Exceptional Conditions, took its place at tenth, covering improper error handling and logical failures that leave systems in an insecure state.

A01: Broken Access Control

Still the most common and consequential risk on the list, holding the top spot across both the 2021 and 2025 rankings, now expanded to include SSRF-style attacks explicitly. This is when a user can access data or functionality they shouldn't be able to — a user changing an id parameter in a URL to view another user's private data, or tricking your server into making requests to internal services it shouldn't reach.

How we defend against it: deny-by-default policies enforced on the server, never the frontend. Every API request is both authenticated (who is this?) and authorized (does this user actually own this data?), and any server-initiated outbound request is validated against an allowlist to prevent the SSRF-style abuse now formally folded into this category.

A02: Security Misconfiguration

Now the second most critical risk category, up from fifth in the 2021 list — a genuinely significant reranking, and one that matches what security practitioners have been observing anecdotally for years, reflecting how often real breaches trace back to a misconfigured cloud resource rather than a code-level bug. Default credentials left active, debug mode enabled in production, a cloud storage bucket left publicly accessible.

How we defend against it: Infrastructure as Code, so environment configuration is version-controlled and peer-reviewed like application code, plus automated security scanning in CI/CD that catches misconfigurations before deployment, not after.

A03: Software Supply Chain Failures (New Category)

This is the most significant new addition to the list, and arguably the change most worth understanding in depth, expanding well beyond simply "using an outdated library." It now explicitly covers compromised dependencies, insecure build pipelines, and distribution infrastructure — the kind of attack where the vulnerability isn't in code your team wrote at all, but in the tools and packages your build process trusts implicitly.

How we defend against it: automated dependency scanning run continuously, verified package integrity checks in CI/CD, and a documented, minimized build pipeline where every step that touches your code or its dependencies is itself treated as part of your security surface, not an assumed-trustworthy black box.

A04: Cryptographic Failures

Failing to properly encrypt sensitive data, both in transit over the network and at rest in your database — including weak or missing password hashing.

How we defend against it: HTTPS/TLS enforced everywhere, sensitive data encrypted at rest in our databases, and passwords never stored in any recoverable form — only securely hashed and salted using modern algorithms like bcrypt.

A05: Injection

The classic vulnerability class, most famous as SQL injection — where an attacker manipulates user input to execute unintended database commands, potentially exposing your entire database from something as simple as a login form.

How we defend against it: we never build queries by concatenating raw strings with user input. Modern ORMs (Prisma, TypeORM) use parameterized queries by default, which structurally prevents this class of vulnerability rather than relying on developers to remember to sanitize every input manually.

A06: Insecure Design

A subtler category — this isn't a coding bug, but a flaw in the business logic itself. A ticket transfer feature with no limit on how many times a ticket can be re-transferred, enabling fraud, is a design flaw, not a bug a code review would catch.

How we defend against it: threat modeling during discovery, before any code is written — explicitly asking "how could this feature be abused?" for every significant piece of business logic, not just reviewing code for syntax errors after the fact.

The Rest of the 2025 List, Briefly

• A07: Authentication Failures. Weak password policies or no protection against brute-force attempts. Rate limiting, strong password requirements, and multi-factor authentication address this directly.
• A08: Software or Data Integrity Failures. Not verifying the integrity of data or code — failing to validate a JWT signature, for instance. Every token and payload should be strictly validated, never trusted implicitly.
• A09: Security Logging and Alerting Failures. Not having the logs — or the alerting on top of them — to even know if you were breached. Robust logging paired with real alerting on suspicious activity turns "we don't know if we were compromised" into "we'd know within minutes."
• A10: Mishandling of Exceptional Conditions (New Category). Improper error handling, logical errors, and "fail open" scenarios where a system defaults to an insecure state when something goes wrong rather than safely denying access. A payment validation step that silently allows a transaction through when its fraud-check service times out, for instance, is exactly this failure mode.

When the new list published in January 2026, we treated it as a mandatory internal review, not an optional update to note and move past. Our security-focused engineers ran our own standard project checklist against the two new categories specifically, updated our internal architecture review templates to explicitly prompt for supply-chain and exceptional-condition handling considerations during discovery, and rolled the updated checklist out across every active client engagement rather than only applying it to new projects going forward. This is genuinely the kind of update that separates a security practice that's actually alive and current from one that's frozen at whatever guidance existed when a team first wrote its internal checklist years ago and never revisited it since.

Passing an OWASP Top 10 review once doesn't mean you're secure indefinitely — new dependencies get added, new features introduce new attack surface, and the threat landscape itself evolves in ways that even a five-year gap between official list revisions doesn't fully capture, as this first major list revision since 2021 demonstrates clearly. Real security maturity means these checks run continuously, as part of your development pipeline, not as a pre-launch audit that gets treated as "done" afterward and never revisited as the list itself evolves.

It's worth dwelling on Software Supply Chain Failures specifically, since it's the category most teams are least prepared for given how new the formal framing is. Modern applications routinely depend on hundreds of third-party packages, each with their own maintainers, their own build processes, and their own potential for compromise — a single malicious update pushed to a popular, trusted package can silently propagate into thousands of downstream applications before anyone notices. Real defense here goes beyond simply running npm audit occasionally: it means pinning dependency versions deliberately rather than always pulling the latest release automatically, verifying package integrity through lockfiles and checksums, minimizing the total number of dependencies a project actually needs, and treating your CI/CD pipeline itself — the scripts, the runners, the credentials they have access to — as security-sensitive infrastructure worthy of the same scrutiny as your production application code.

Security is a process and a culture, not a feature you ship once — and the first OWASP Top 10 revision in five years is a clear reminder that the threat landscape keeps moving even when your codebase doesn't. Building continuous security into your development pipeline — threat modeling, automated scanning across the full supply chain, and robust monitoring — is what separates an application that's secure in a demo from one that stays secure in production, under real-world attack conditions, against a risk list that will keep evolving.

Ready to build your application on a foundation of genuine, continuous, current security?