OWASP Top Ten 2025 – The Complete Guide

Updated Nov 7th, 2025

OWASP Top 10 (2025 Release Candidate): Key Shifts and New Threats

The OWASP Top 10 2025 exists as a guide to the 10 most important web application vulnerabilities, based on a wide-ranging industry survey. It helps developers and security teams focus on the most impactful threats, allowing them to allocate resources effectively.

While it isn’t a complete security framework, it serves as a standard awareness document for developers, ensuring they are aware of and trained on the most common and dangerous security risks. It’s often used as a baseline for compliance checks and security audits, influencing vendor questionnaires and procurement processes, and its latest iteration reflects the complex and interconnected nature of modern threats.

The OWASP Top 10 2025 Release Candidate, published on November 7, 2025, marks the final stage of community consultation before the official list is released. It serves as a near-final draft, allowing researchers, developers, and industry experts to provide feedback before OWASP finalizes the rankings and descriptions. While only minor refinements are expected, the release candidate offers a reliable preview of the priorities and trends that will define the official OWASP Top 10 – 2025 when it is formally published in early 2026.

Two new categories appear this year, Software Supply Chain Failures and Mishandling of Exceptional Conditions, while Server-Side Request Forgery (SSRF) has been absorbed into other areas.

1. Broken Access Control (unchanged – still #1)

Broken access control remains at the top of the OWASP list for 2025, just as it did in 2021.

It occurs when an application doesn’t properly enforce restrictions on what users are allowed to do. This lets attackers access data, functions, or systems that should be off-limits — for instance, viewing or editing another user’s records, or performing admin-level actions without authorization.

One example of BAC is horizontal privilege escalation, where a user can change a URL such as `/profile/677` (their own account) to `/profile/678` to view someone else’s account.

Another is vertical privilege escalation, where a regular user performs admin-level actions — like accessing `/admin` — without proper checks. Attackers exploit these flaws by disabling client-side controls, manipulating requests, or guessing object IDs.

Then there are CORS misconfigurations, which occur when a web application allows cross-origin requests from untrusted domains. This can expose sensitive data by letting malicious sites make unauthorized requests on behalf of users.

Mitigation: Implement robust access controls such as role-based or attribute-based access control (RBAC/ABAC), validate all permissions on the server side, and follow the principle of least privilege, ensuring each user has access only to what they truly need.

Note: SSRF, previously a standalone category in 2021, has now been absorbed under broader access-control and input-validation weaknesses.

2. Security Misconfiguration (moved up from #5)

Security misconfiguration has surged from #5 to #2, which isn’t too big a surprise given how often breaches stem from cloud or infrastructure settings rather than straightforward code flaws.

It occurs when servers, frameworks, or services are deployed with default credentials, verbose error messages, unnecessary features, or missing patches.
Attackers exploit these gaps to gain unauthorized access or harvest sensitive data.

Mitigation:

• Disable defaults and unnecessary components
• Enforce hardened configurations
• Automate configuration scanning
• Apply least-privilege principles
• Keep all environments patched and consistent

3. Software Supply Chain Failures (new category)

Replacing the previous “Vulnerable and Outdated Components” in the 2021 list, this new category draws attention to the broader risk of supply-chain compromise: vulnerabilities in third-party libraries, build pipelines, container images, CI/CD tools, and software distribution mechanisms.

Modern applications rely heavily on external components, frameworks, services, and automated pipelines. When any link in that chain is compromised, the blast radius is magnified: a single poisoned library or build system can propagate malicious functionality across hundreds or thousands of downstream applications (as happened in the Polyfill.io case). Attackers are increasingly exploiting this vector rather than just attacking a single app.

What real-world attacks show

Data shows supply chain attacks are accelerating: for example, attacks averaged just under 13 per month during early 2024 but rose to over 16 per month from October 2024 to May 2025 — and some months (April/May) hit nearly 25.

In October 2025 alone, 41 supply chain incidents were claimed — more than 30% higher than any previous month.

A stark example: a self-replicating malware campaign dubbed Shai‑Hulud compromised dozens (and perhaps hundreds) of npm packages in September 2025, injecting credential-stealers, modifying build workflows, and using stolen tokens to spread further.

The implications are wide-ranging: one compromised component can lead to “trusted” software delivering malicious code; build environments themselves are now targets; and downstream users may be unaware they are affected.

This marks a major evolution in the Top 10 — shifting the focus from outdated components to full supply-chain resilience.

4. Cryptographic Failures (moved down from #2)

Previously #2, Cryptographic Failures now sit at #4, reflecting that while encryption standards are improving, implementation errors are still a leading cause of data exposure.

These sorts of failures occur when applications don’t adequately protect sensitive information through strong cryptographic controls. Examples include:

• Transmitting data over HTTP instead of HTTPS
• Using weak or outdated algorithms (MD5, SHA-1, DES, RC4)
• Implementing reversible password encryption instead of hashing
• Hard-coding encryption keys in source code
• Improper TLS configuration or unverified certificate chains
• Storing personal or financial data in plaintext

Weaknesses like these allow attackers to intercept or decrypt sensitive data, perform credential replay, or reconstruct passwords using rainbow tables.

Mitigation:

• Classify data and apply encryption both in transit and at rest
• Use well-vetted algorithms (AES-256, SHA-256, TLS 1.3)
• Hash passwords with bcrypt, scrypt, or Argon2
• Manage keys securely — never hardcode them, and rotate regularly
• Enforce HTTPS and HSTS site-wide
• Use cryptographically secure random number generators for key and token generation

Although this category dropped two places in the 2025 ranking, its number four ranking acknowledges that even mature organizations still struggle with implementation and key management practices.

5. Injection (moved down from #3)

Injection vulnerabilities — including SQL, OS command, NoSQL, and LDAP injection — have dropped from #3 to #5 in the 2025 list, but they remain among the most exploited and widely understood web security issues.

At its core, an injection flaw occurs when untrusted data is passed directly into an interpreter — such as a SQL query, command shell, or template engine — without proper validation or escaping. Attackers can then manipulate how that interpreter behaves, often forcing it to execute arbitrary commands or leak sensitive data.

Common types of injection

• SQL Injection: The most notorious example, where malicious SQL fragments are injected into a query. Attackers can read, modify, or delete data, or even execute administrative database operations.
• Example: appending ‘ OR ‘1’=’1 to a login query to bypass authentication.

• Command Injection: Occurs when unsanitized input is passed to system commands (e.g., ping or cat). This can allow full operating-system compromise.

• NoSQL Injection: A modern variant affecting MongoDB, Firebase, and other NoSQL stores, often caused by unsanitized JSON queries.

• LDAP or XPath Injection: Exploits that manipulate directory or XML queries to access unauthorized records.

• Cross-Site Scripting (XSS): Although sometimes treated separately, many OWASP resources consider XSS a subset of injection, since it involves injecting untrusted data into a browser context.

Even with frameworks offering built-in protections, injection flaws persist because developers often:

• Build dynamic queries by string concatenation

• Fail to use parameterized APIs

• Don’t validate or sanitize user input correctly

• Trust client-side input or JavaScript filtering

• Use legacy code that predates modern secure coding practices

And while newer architectures (e.g., GraphQL, microservices, and serverless APIs) reduce some exposure, they introduce others — for instance, GraphQL query injection or template injection in serverless frameworks.

Mitigation

• Use parameterized queries or prepared statements that strictly separate SQL logic from user input

• Employ stored procedures and avoid dynamic query building

• Apply allow-list input validation rather than block-lists

• Use context-appropriate output encoding (e.g., HTML, URL, or JavaScript escaping)

• Apply least privilege to database and OS accounts

• Scan applications regularly with SAST/DAST tools and include injection checks in automated testing

• Consider Web Application Firewalls (WAFs) for additional detection and protection

Even though Injection has dropped to fifth place in 2025, it remains one of the most dangerous and easily exploitable weaknesses — and the one that continues to surface in high-profile breaches more than two decades after OWASP’s first Top 10 list.

6. Insecure Design (moved down from #4)

Insecure design slides from #4 to #6, underscoring the industry’s gradual adoption of secure design principles — but also highlighting how design oversights still drive vulnerabilities.

It refers to flaws in architecture or logic rather than implementation mistakes: weak password-reset flows, lack of threat modeling, or missing authorization steps.

Mitigation:
Integrate security early in the SDLC, conduct threat modeling, adopt secure design patterns, and perform design-stage reviews before implementation.

7. Authentication Failures (renamed – used to be called “Identification & Authentication Failures”, same position)

The renamed Identification and Authentication Failures is a non-mover on the OWASP 2025 list, but these remain a major enabler of unauthorized access, account takeover, and data breaches. These failures occur when systems do not properly verify or protect user identities and authentication mechanisms, allowing attackers to impersonate legitimate users or escalate privileges.

Common causes and attack vectors

• Weak or reused passwords: Many users still rely on guessable or recycled credentials, making them vulnerable to brute force and credential stuffing attacks using data from other breaches.

• Lack of Multi-Factor Authentication (MFA): Without MFA, a stolen or guessed password alone can compromise accounts, even high-privilege ones.

• Session management flaws: Exposed, predictable, or unexpired session tokens can allow attackers to hijack authenticated sessions.

• Poor credential recovery mechanisms: Weak “forgot password” flows or insecure reset links often provide an easy way in.

• Insecure storage of credentials: Passwords or session tokens stored in plaintext, logs, or browser caches are a persistent risk.

These vulnerabilities continue to appear in real-world attacks. Credential stuffing campaigns and automated botnets target login endpoints at scale, exploiting weak rate-limiting and poor monitoring. Even MFA can be subverted when applications don’t properly validate tokens or use insecure channels (like SMS), vulnerable to SIM swapping or interception.

Mitigation and best practices

• Enforce strong password policies aligned with NIST guidelines, including length and entropy rather than arbitrary complexity rules.

• Implement MFA everywhere, ideally using phishing-resistant methods such as FIDO2, WebAuthn, or hardware security keys.

• Secure session management by rotating tokens, setting strict timeouts, and using secure cookies with HttpOnly and SameSite attributes.

• Harden credential recovery workflows, using time-limited, single-use reset links and verified communication channels.

• Monitor authentication events for anomalies such as multiple failed logins, unusual IP locations, or simultaneous sessions.

• Hash passwords with adaptive, salted algorithms like Argon2, bcrypt, or PBKDF2 — never store them in plaintext or reversible form.

While identification and authentication failures may have slipped slightly in rank, they remain central to nearly every security incident. Weak authentication often turns what would have been a minor misconfiguration into a full-scale breach.

8. Software or Data Integrity Failures (same position)

Still at #8 (with a minor wording change from “and” to “or”), this category deals with untrusted code or data being accepted without verification. That includes compromised CI/CD pipelines, unsigned software updates, or deserialization flaws.

Mitigation:
Verify code signatures, implement integrity checks, use trusted sources, and protect build and deployment processes from tampering.

9. Logging & Alerting Failures (renamed – was “Security Logging and Monitoring Failures”, same position)

Although the title has been shortened, the meaning remains consistent. Logging and alerting failures prevent teams from detecting and responding to breaches promptly.

Missing logs, ignored alerts, or inadequate monitoring allow attackers to operate unnoticed.

Mitigation:
Enable comprehensive logging for security events, integrate with SIEM systems, automate alerts, and perform regular log reviews.

10. Mishandling of Exceptional Conditions (new category)

This is a brand-new entry for 2025. It focuses on poor handling of unexpected or “exceptional” situations — errors, timeouts, logic failures, or invalid states that applications fail to handle securely.

This kind of mishandling can lead to information leaks, bypassed controls, or denial-of-service conditions.

Mitigation:

• Implement consistent, secure error-handling patterns
• Avoid exposing stack traces or sensitive debug data
• Fail safely (fail-closed, not fail-open)
• Log exceptions for analysis while keeping responses user-safe

This addition replaces the 2021 category “Server-Side Request Forgery (SSRF)”, which is now treated as a subset of broader input-validation and access-control weaknesses.

Summary of 2025 Changes

Final Thoughts

The OWASP Top 10 2025 Release Candidate highlights how attackers, and defenders, have evolved. The focus now extends beyond insecure code to the larger ecosystem that supports it: design, configuration, dependencies, and supply-chain trust.

If your organization wants to stay ahead, build a culture of continuous security — from design through deployment — and remember that good visibility, solid configuration, and careful dependency management are now every bit as critical as secure coding.