The OWASP Top 10 is updated approximately every three to four years, and each update reflects changes in how web applications are built, how they're attacked, and what the security community has learned from breaches and vulnerability disclosures in the intervening period. The 2025 edition carries forward continuity from 2021 while shifting emphasis in ways that matter for engineering teams using modern frameworks, cloud-native infrastructure, and AI-assisted tooling in their development workflows.
This isn't a summary of the Top 10 list — you can read that at owasp.org. This is an analysis of what's shifted, what the shifts mean for teams training engineers and reviewing code, and which training modules need to be updated as a result.
What remained stable: Broken Access Control at the top
A01 (Broken Access Control) remains the most common vulnerability category and has been at or near the top since the 2021 edition elevated it from A05 in 2017. The 2025 update doesn't change this ranking — the data from CVE databases and bug bounty platforms consistently shows authorization logic failures as the most commonly exploited vulnerability class in production web applications.
The 2025 edition expands the A01 description to more explicitly include API-level authorization failures — BOLA (Broken Object Level Authorization, OWASP API Security API1) language migrates into the main Top 10 as the API security model matures. This reflects the reality that the web application boundary and the API boundary have merged for most modern applications. If your training program separates "web AppSec" and "API security" into different tracks, the 2025 Top 10 is a signal to integrate them.
A04: Insecure Design — the new category that's still misunderstood
A04 (Insecure Design) was introduced in the 2021 edition and generated the most confusion of any new category in recent OWASP history. The 2025 edition refines the description to more clearly distinguish Insecure Design from Insecure Implementation.
Insecure Design is about design decisions that have no corresponding security control, regardless of implementation quality. A password reset flow that sends the new password to the original email address — without any time-limited token or verification — is an insecure design. You can implement that design flawlessly and it remains insecure. A correctly designed password reset flow uses a time-limited token, confirms the reset via a secondary mechanism, and invalidates existing sessions after the reset completes. Implementation quality doesn't compensate for design-level decisions that omit necessary security controls.
The practical implication for engineering teams: threat modeling at the design stage is the appropriate mitigation for A04. Secure code review catches implementation flaws (A03, A05, etc.). It cannot catch insecure design decisions because the code correctly implements the design — the problem isn't in the implementation. This is the strongest argument in the OWASP framework for doing threat modeling before writing code, not as an afterthought.
A08: Software and Data Integrity Failures — broader scope in 2025
A08 (Software and Data Integrity Failures) covers a range of integrity-related vulnerabilities that have expanded in practical importance. In 2021, this category was primarily focused on CI/CD pipeline integrity and deserialization vulnerabilities. In 2025, the scope broadens to include:
Supply chain integrity — the dependency confusion and package substitution attacks documented in 2021 and after. This includes not just npm and pip packages but container base images, CI/CD action versions (the actions/checkout@v4 pattern where version tags are mutable without digest pinning), and IaC module sources.
Auto-update mechanisms that don't verify code signatures. An update mechanism that downloads and executes code without cryptographic verification of its source and integrity is a supply chain attack surface regardless of how secure the rest of the application is.
For teams reviewing their A08 exposure, the practical starting point is inventory: what does your build pipeline fetch from external sources? Package registries, base images, build actions, test fixtures, deployment scripts. Each external source without integrity verification is an A08 exposure.
The AI-related additions: what they actually cover
The 2025 OWASP Top 10 does not add a separate "AI vulnerability" category to the web application list. This is a deliberate choice — the OWASP Top 10 for LLM Applications (a separate project) covers AI-specific vulnerabilities. The main Top 10 applies to web applications, which increasingly incorporate AI components but aren't AI applications themselves.
What the 2025 edition does acknowledge, within A04 and A08, is that AI-assisted code generation introduces specific integrity concerns. Code generated by language models and committed without security review has been observed to introduce A03 injection patterns, A02 cryptographic failures (using deprecated algorithms by default), and A01 access control omissions. These aren't new vulnerability classes — they're the same classes, with a new causal pathway.
The implication for training: security code review training needs to explicitly address AI-generated code as a review target. The review questions are the same ("is authorization enforced here?" "is this query parameterized?") but engineers need to know that AI-generated code requires the same scrutiny as human-written code — possibly more scrutiny, because the volume of AI-generated code in a review can create cognitive overload that leads to less careful review of each change.
A09: Security Logging and Monitoring — still underweighted in practice
A09 (Security Logging and Monitoring Failures) has appeared in every edition since 2017. Its persistent presence reflects the reality that it remains an area where most organizations underinvest. The 2025 edition strengthens the connection between A09 and A01 — broken access control attacks often run undetected precisely because the logging doesn't capture enough context to distinguish authorized access from unauthorized access by a compromised account.
The 2025 language specifically calls out authentication event logging completeness — recording not just authentication failures but the full context needed to detect credential stuffing (source IP, user-agent, timing patterns) and session anomalies (geographic impossible-travel, unusual access patterns for the authenticated identity). This is not technically complex logging. It's logging that most teams simply haven't prioritized because it doesn't appear in sprint acceptance criteria.
What your training modules need to reflect
Three updates based on the 2025 Top 10 that should be reflected in security training content:
Add supply chain security to A08 coverage. If your secure development training mentions A08 only in the context of deserialization, it's missing the supply chain attack surface that's become the dominant A08 concern in real breach cases since the SolarWinds (2020), Codecov (2021), and XZ Utils (2024) incidents.
Ensure threat modeling training explicitly connects to A04. Engineers who learn STRIDE methodology but don't understand that threat modeling is specifically the mitigation for Insecure Design won't see threat modeling as essential rather than optional.
Include AI-generated code review in code review training. Not as a separate track, but as an explicit reminder that the review questions are unchanged and the standards are unchanged — the origin of the code doesn't affect whether it meets security requirements.
The OWASP Top 10 is a reference framework, not a complete security curriculum. Its value is in giving engineering teams a shared vocabulary for vulnerability classes and a data-grounded sense of what's worth prioritizing. The 2025 edition's direction — more explicit about design-level failures, more explicit about supply chain, more explicit about the logging gap — reflects where real-world attacks have focused over the past three years. That direction is worth following in how your team trains and what your code review processes check.
