OWASP Top Ten 2025 – The Complete Guide

Updated Dec 4th, 2025

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

The OWASP Top 10 2025 is intended to be a guide to the 10 most important 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 understand 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 updated 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. Only minor refinements are expected, so 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.

There are two new categories 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. It occurs when an application doesn’t properly enforce restrictions on what users are allowed to do. It 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. These 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
• Follow the principle of least privilege, ensuring each user can only access what they truly need.

2. Security Misconfiguration (moved up from #5)

Security misconfiguration has surged from #5 to #2, not surprisingly, given how many breaches stem from incorrect cloud or infrastructure settings rather than straightforward code flaws.

The problem arises 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 targeting 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, there were 41 supply chain incidents, more than 30% higher than any previous month.

One example is the self-replicating malware campaign dubbed Shai‑Hulud. It compromised dozens 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 not be aware they are affected.

Mitigation

• Maintain a complete inventory of dependencies (including libraries, modules, containers, and services).
• Use software bills of materials (SBOMs) to understand what components are in your supply chain.
• Ensure secure build pipelines: control access, verify artifacts (unsigned code = bigger risk), and restrict who or what can publish dependencies.
• Monitor and scan for compromised libraries and announced vulnerabilities; adopt dependency updates proactively, not just reactively.
• Enforce least privilege for build systems, automate verification (code-signing, integrity checks), and isolate critical build infrastructure from general user networks.
• Consider tools that detect and remediate malicious or compromised components (for example, regenerating libraries to eliminate hidden backdoors).
• Educate developers about the risks of third-party dependencies and build automations.

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.

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 position 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.

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. 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.

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 modelling
• Adopt secure design patterns
• 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. They 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) that are 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 still seem to show up in nearly every security incident. Weak authentication often turns what would have been a minor misconfiguration into a full-scale breach.

8. Software and Data Integrity Failures (same position)

This category now encompasses a broader range of risks tied to supply chain compromise, tampering, and unverified updates. These vulnerabilities occur when code, configurations, or data are modified without proper validation, allowing attackers to insert malicious content into trusted environments.

Since the 2021 list, real-world incidents have exposed just how dangerous integrity failures can be. Notable examples include:

• The SolarWinds Orion attack (2020): where attackers inserted a backdoor into legitimate update packages, compromising thousands of organizations.

• The Codecov breach (2021): where attackers tampered with a CI/CD script used in hundreds of build pipelines.

• The previously mentioned Polyfill.io supply chain compromise.

Each of these attacks exploited weaknesses in the way software components were built, signed, and distributed, proving that even “trusted” code can be weaponized when integrity isn’t rigorously verified.

Common causes

• Untrusted updates or dependencies: Software packages or libraries downloaded without signature verification.

• Compromised CI/CD pipelines: Attackers inserting malicious code into automated build or deployment processes.

• Unsigned or tampered data: Applications failing to verify file or payload integrity using checksums or digital signatures.

• Insecure deserialization: Allowing untrusted data objects to reconstitute server-side code or commands.

• Improper use of third-party integrations: Using external scripts or APIs without validating their authenticity or integrity.

Mitigation

To prevent software and data integrity failures, organizations must move beyond simple patching and implement a trust-by-design approach:

• Digitally sign and verify all software and update packages using trusted certificates or GPG keys.

• Secure CI/CD pipelines with least privilege, secret management, and tamper-proof build processes.

• Implement Software Bill of Materials (SBOMs) to track dependencies and quickly identify at-risk components.

• Adopt integrity verification mechanisms such as checksums, code signing, and reproducible builds.

• Harden dependency management systems, ensuring only verified sources are used for libraries and packages.

• Validate deserialization inputs and avoid insecure serialization formats whenever possible.

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

These failures occur when an organization either doesn’t collect the right security telemetry, doesn’t monitor it effectively, or can’t act quickly enough on alerts. Without proper logging and monitoring, even basic attacks can escalate into full compromises, data breaches, or ransomware events.

Common symptoms and weaknesses

• Incomplete or missing logs: Critical events,  such as failed logins, privilege escalations, or administrative actions, are not logged.

• Poor log retention: Logs are overwritten or deleted before forensic analysis can take place.

• Unmonitored alerts: Security Information and Event Management (SIEM) systems generate warnings that no one reviews.

• Uncorrelated data sources: Logs from different systems (cloud, app, database) are siloed, preventing analysts from connecting events.

• Lack of response procedures: Even when alerts are triggered, teams may not have playbooks or escalation paths to act.

Real-world incidents, such as the MOVEit and SolarWinds breaches, show that attackers can remain undetected in networks for weeks or months, often because systems failed to record or flag unusual activity early enough. Many ransomware groups now deliberately disable or erase logging systems during attacks to conceal their presence.

Mitigation and best practices

• Comprehensive logging: Capture authentication attempts, data access, configuration changes, and administrative actions.

• Centralized log management: Aggregate logs into a SIEM or cloud-native service for real-time analysis and correlation.

• Alert tuning and automation: Use behavioral baselines, anomaly detection, and automated alerting to identify suspicious patterns.

• Retention and protection: Store logs securely for sufficient periods (typically 90–180 days or longer), ensuring integrity and non-repudiation.

• Integration with incident response: Link alerts to playbooks, ticketing systems, and security orchestration tools (SOAR) for rapid response.

• Regular audits and testing: Conduct log review exercises and detection drills to ensure coverage and effectiveness.

Logging and monitoring failures are now less about missing data and more about missing insight.

10. Mishandling of Exceptional Conditions (new category)

This brand-new entry for 2025 highlights a long-overlooked class of risk: applications that break unsafely when faced with unexpected inputs, resource shortages, timeouts, or internal failures.

Poor exception handling can leak sensitive data (stack traces, keys), bypass controls (fail-open logic), or trigger denial-of-service. These flaws often fly under the radar in vulnerability scans because they manifest only under stress—yet 50% of OWASP survey respondents ranked them as their #1 emerging concern.

#10 consolidates 24 CWEs previously scattered across “code quality” issues, including CWE-209 (error messages with secrets), CWE-476 (NULL dereference crashes), and CWE-636 (failing open). SSRF (CWE-918) is now one example within this broader resilience failure.

Mitigation and best practices

• Define secure failure modes: fail closed and deny access on error.
• Use consistent error-handling frameworks; log details internally, return generic messages externally.
• Validate edge cases with fuzz testing and chaos engineering.
• Monitor and throttle resources to prevent exhaustion attacks.
• Centralize exception telemetry for rapid root-cause analysis.
• Never expose stack traces or debug data to users.

By reframing the former SSRF category as Mishandling of Exceptional Conditions, OWASP 2025 underscores how modern security failures increasingly stem not just from bad input validation, but from brittle systems that break and reveal too much under stress. Its inclusion reflects evolving priorities in web application security, shifting focus from purely preventive measures to ensuring systems fail safely and predictably under stress.

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.