23.1.2026

OWASP Top 10 is a list of the ten most critical security risks for web applications, created by the Open Web Application Security Project (OWASP), and has been a central reference in application security for more than two decades. The list provides a common risk language for developers, security professionals, and technical leaders who build and protect software. The updated version for 2025 is now here, and it clearly shows how the threat landscape has evolved since 2021, when the previous version was released.

Briefly about what OWASP Top 10 is and what has changed

OWASP Top 10 2025 is out. The changes are fewer than many might have expected, but they are clear. The focus has shifted away from individual coding errors and toward systemic issues in how applications are built, configured, and operated.

The most interesting changes are not about new types of attacks, but about where flaws actually occur in modern applications. The data behind the 2025 list shows the same picture that many security teams already see in practice. Most serious findings come from access control, misconfiguration, and dependencies that are not fully under control.

OWASP Top 10 is updated approximately every three to four years, based on a comprehensive dataset of real vulnerability findings, contributions from the security community, and analysis of real-world attacks. The list is therefore less of a theoretical framework and more a distillation of what recurs in modern applications. The changes between each version are usually incremental, but they provide a clear picture of how risk areas and attack surfaces shift over time.

OWASP Top 10 2025

The final list of the ten most critical security risks in web applications looks like this:

1. Broken Access Control
2. Security Misconfiguration
3. Software Supply Chain Failures
4. Cryptographic Failures
5. Injection
6. Insecure Design
7. Authentication Failures
8. Software or Data Integrity Failures
9. Security Logging and Alerting Failures
10. Mishandling of Exceptional Conditions

Compared to 2021, the structure is familiar, but several categories have been moved, merged, or expanded. The changes reflect how real attacks are carried out today.

Reference: https://owasp.org/Top10/2025/0x00_2025-Introduction/

Software Supply Chain Failures

The most significant change in the 2025 edition is the introduction of Software Supply Chain Failures as its own category. This effectively replaces Vulnerable and Outdated Components from 2021 and significantly expands the scope.

The focus is no longer only on vulnerable libraries. The category covers the entire chain around the software:

• Third party dependencies
• CI and CD pipelines
• Package management and distribution
• Trust in external vendors
• Exposure of stack traces and internal information
• Applications that fail open instead of failing secure
• Insufficient handling of timeouts, exceptions, and edge cases

Supply chain attacks have proven to be both scalable and effective. When code is compromised before it reaches production, many traditional security controls are bypassed. This is also clearly reflected in practice. During penetration testing, this type of weakness almost always appears. Often not as an isolated finding, but as a systemic weakness in how the environment is set up. Typical examples are uncontrolled dependencies, lack of restrictions in building pipelines, and implicit trust in third party components that no one has actually verified. This is also an area that many customers and organizations systematically underestimate. The focus is often on their own code, while everything around it is assumed to be safe as long as it works. In practice, this is precisely where the attack surface has grown the most in recent years. Supply chain risks are also an area that NIS and NIS2 place requirements on in EU legislation.

Mishandling of Exceptional Conditions

Mishandling of Exceptional Conditions is a new category in 2025. It addresses errors that occur when applications end up in states they were not designed to handle.

This includes among other things:

• Exposure of stack traces and internal information
• Applications that fail open instead of failing secure
• Insufficient handling of timeouts, exceptions, and edge cases

In distributed systems and API based architectures, such failures can have greater consequences than before. Errors in one service propagate quickly to others.

SSRF is no longer a separate category

Server-Side Request Forgery had its own place in OWASP Top 10 2021. In 2025 it has been removed as a separate category and merged into Broken Access Control.

This reflects how SSRF typically occurs in practice. The attack succeeds because the application does not restrict which internal resources it is allowed to access. This is an access control problem and not an isolated input problem.

Security Misconfiguration has moved up

Security Misconfiguration has moved up to second place in 2025. This aligns well with findings from both testing and real incidents.

Misconfigurations occur in cloud environments, containers, API gateways, and authentication solutions. They are often caused by default settings, copied configurations, or lack of visibility into what is exposed.

Configuration is still handled manually in many environments, even where the rest of the development lifecycle is automated.

In addition, we see a concerning trend where projects rely on cloud solutions because they are perceived as secure. It appears that many project managers believe responsibility for security configuration is also delegated to the cloud provider, which is rarely the case. The cloud provider sets up a standard operating environment with some default controls, but it is still the customer who must tune the configuration for their specific application. This becomes more demanding when you do not host the infrastructure yourself. Arguments such as “We do not need authentication because the application is hidden behind a random IP address that only we and the cloud provider know” have actually been used. This opens the system to anyone randomly scanning IP addresses, and that is not good security.

Injection and Cryptographic Failures

Injection and Cryptographic Failures are still part of the OWASP list but carry less weight than before. This indicates increased maturity in the use of frameworks and libraries. Classic mistakes are harder to make, but they have not disappeared entirely. When they occur today, they are often tied to legacy code or special cases where standard mechanisms are bypassed. For Cryptographic Failures, this is especially visible around TLS configuration and key management. Weak or outdated TLS configurations, incorrect certificate validation, and key reuse are recurring findings in testing. Often the cryptography itself is correct but used incorrectly in context. For example, when TLS is terminated incorrectly, internal traffic is assumed to be trusted, or custom implementations are introduced where established mechanisms already exist.

Many still allow communication over TLS version 1.2 or lower because many older systems have not been upgraded. This provides backward compatibility but be aware that today the security requirement is TLS version 1.2 or higher. It is better to require that legacy systems are upgraded to a secure version than to reduce security in the new application.

What the list says about today’s applications

OWASP Top 10 2025 clearly points to fundamental control issues

1. Missing or incorrect access control
2. Insufficient configuration control
3. Unclear trust in code and components

These problems are not solved with simple patches. They require clear structure, defined ownership, and continuous follow up throughout the entire application lifecycle. In practice, this means that security must be anchored in established frameworks and governance principles, not left to individuals or ad hoc measures. It also shows that security must be part of the design phase and cannot be added at the end of a project. At that point, the cost of re-engineering the solution and replacing insecure infrastructure components often kills the system before it can be put into use. The concept of Security by Design, Security by Default is important to carry forward when starting development of a new solution.

When it comes to access control, I see that more organizations use multi factor authentication on all their cloud systems. That is generally positive, but it removes the distinction between low and high-risk systems when it comes to access. Good security thinking requires additional layers of protection between different risk classes. One should either require a new authorization step with different MFA factors to access high risk systems or use a secure single sign on solution for one class as an additional layer. Only users defined in a separate security group should then have access to high-risk systems.

For Nordic organizations, there are established frameworks that provide a solid starting point for this work. In Norway, NSM’s basic principles for ICT security are widely used, while similar principles exist at MSB in Sweden. What these frameworks have in common is a focus on governance and control, protection of systems and data, and the ability to detect and handle incidents. When such frameworks are actively used in development and operations, they provide structure that supports many of the risk areas highlighted by OWASP Top 10.

This includes defined security requirements in the design phase, clear responsibility for access management and configuration, and continuous verification through testing and monitoring. Without this type of structure, the same findings will continue to appear regardless of how many vulnerabilities are patched along the way.

OWASP Top 10 2025 does not point to new problems. It documents that the same fundamental weaknesses still exist in modern applications, even in environments perceived as technically mature. The cause is rarely the choice of technology, but how security is followed up in practice over time.

Organizations that have structure, ownership, and continuous follow up reduce risk systematically. Those that do not will continue to uncover the same findings year after year, regardless of cloud platform, framework, or development methodology. OWASP Top 10 therefore functions less as a warning list and more as a maturity mirror.

So, what should be prioritized

Based on the 2025 list, three measures provide the greatest effect

1. Access control must be explicitly designed, documented, and tested
2. Configuration must be automated and continuously verified
3. Supply chain risks must be handled as part of normal development

OWASP Top 10 2025 shows a familiar picture and aligns well with what is actually uncovered in testing and incident response. The biggest security problems still come down to the fundamentals.