Next Steps

By design, the OWASP Top 10 is innately limited to the ten most significant risks. Every OWASP Top 10 has “on the cusp” risks considered at length for inclusion, but in the end, didn't make the cut. The other risks were more prevalent and impactful.

The following two issues are well worth the effort to identify and remediate, organizations working towards a mature appsec program, security consultancies, or tool vendors wishing to expand coverage for their offerings.

X01:2025 Lack of Application Resilience

Background.

This is a renaming of 2021’s Denial of Service. That was renamed as it described a symptom rather than a root cause. This category focuses on CWEs that describe weaknesses that are related to resilience issues. The scoring of this category was very close with A10:2025-Mishandling of Exceptional Conditions. Relevant CWEs include: CWE-400 Uncontrolled Resource Consumption, CWE-409 Improper Handling of Highly Compressed Data (Data Amplification), CWE-674 Uncontrolled Recursion, and CWE-835 Loop with Unreachable Exit Condition ('Infinite Loop').

Score table.

CWEs Mapped	Max Incidence Rate	Avg Incidence Rate	Max Coverage	Avg Coverage	Avg Weighted Exploit	Avg Weighted Impact	Total Occurrences	Total CVEs
16	20.05%	4.55%	86.01%	41.47%	7.92	3.49	865,066	4,423

Description.

This category represents a systemic weakness in how applications respond to stress, failures, and edge cases that it is unable to recover from failure. When an application does not gracefully handle, withstand, or recover from unexpected conditions, resource constraints, and other adverse events it can easily result in availability issues (most commonly), but also data corruption, sensitive data disclosure, cascading failures, and/or bypasses of security controls.

Furthermore X02:2025 Memory Management Failures can also lead to failure of the application or even the entire system.

How to prevent

In order to prevent this type of vulnerability you must design for failure and recovery of your systems.

Add limits, quotas, and failover functionality, paying special attention to the most resource consuming operations
Identify resource intensive pages and plan ahead: Reduce attack surface especially not exposing unneeded ‘gadgets’ and functions that require a lot of resources (e.g. CPU, memory) to unknown or untrusted users
Perform strict input validation with allow-lists and size limitations, then test thoroughly
Limit response sizes, and never send raw responses back to the client (process on the server side)
Default to safe/closed (never open), deny by default and roll back if there’s an error
Avoid blocking synchronous calls in request threads (use asynchronous/non-blocking, have timeouts, have concurrency limits, etc.)
Carefully test your error handling functionality
Implement resilience patterns such as circuit breakers, bulkheads, retry logic, and graceful degradation
Do performance and load testing; add chaos engineering if you have the risk appetite for it
Implement and architect for redundancy where reasonable and affordable
Implement monitoring, observability, and alerting
Filter invalid sender addresses in accordance with RFC 2267
Block known botnets by finger prints, IPs, or dynamically by behavior
Proof-of-Work: initiate resource consuming operations at the attackers side that does not have big impacts on normal users but impacts bots trying to send a huge amount of requests. Make the Proof-of-Work more difficult if the general load of the system raises, especially for systems that are less trustworthy or appear to be bots
Limit server side session time based on inactivity and a final timeout
Limit session bound information storage

Example attack scenarios.

Scenario #1: Attackers intentionally consume application resources to trigger failures within the system, resulting in denial of service. This could be memory exhaustion, filling up disk space, CPU saturation, or opening endless connections.

Scenario #2: Input fuzzing that leads to crafted responses that break application business logic.

Scenario #3: Attackers focus on the application’s dependencies, taking down APIs or other external services, and the application is unable to continue.

References.

List of Mapped CWEs

X02:2025 Memory Management Failures

Background.

Languagess like Java, C#, JavaScript/TypeScript (node.js), Go, and "safe" Rust are memory safe. Memory management problems tend to happen in non-memory safe languages such as C and C++. This category scored the lowest on the community survey and low in the data despite having the third most related CVEs. We believe this is due to the predominance of web applications over more traditional desktop applications. Memory management vulnerabilities frequently have the highest CVSS scores.

Score table.

CWEs Mapped	Max Incidence Rate	Avg Incidence Rate	Max Coverage	Avg Coverage	Avg Weighted Exploit	Avg Weighted Impact	Total Occurrences	Total CVEs
24	2.96%	1.13%	55.62%	28.45%	6.75	4.82	220,414	30,978

Description.

When an application is forced to manage memory itself, it is very easy to make mistakes. Memory safe languages are being used more often, but there are still many legacy systems in production worldwide, new low-level systems that require the use of non-memory safe languages, and web applications that interact with mainframes, IoT devices, firmware, and other systems that may be forced to manage their own memory. Representative CWEs are CWE-120 Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') and CWE-121 Stack-based Buffer Overflow.

Memory management failures can happen when:

You do not allocate enough memory for a variable
You do not validate input, causing an overflow of the heap, the stack, a buffer
You store a data value that is larger than the type of the variable can hold
You attempt to use unallocated memory or address spaces
You create off-by-one errors (counting from 1 instead of zero)
You try to access an object after its been freed
You use uninitialized variables
You leak memory or otherwise use up all available memory in error until our application fails

Memory management failures can lead to failure of the application or even the entire system, see also X01:2025 Lack of Application Resilience

How to prevent.

The best way to prevent memory management failures is to use a memory-safe language. Examples include Rust, Java, Go, C#, Python, Swift, Kotlin, JavaScript, etc. When creating new applications, try hard to convince your organization that it is worth the learning curve to switch to a memory-safe language. If performing a full refactor, push for a rewrite in a memory-safe language when it is possible and feasible.

If you are unable to use a memory-safe language, perform the following:

Enable the following server features that make memory management errors harder to exploit: address space layout randomization (ASLR), Data Execution Protection (DEP), and Structured Exception Handling Overwrite Protection (SEHOP).
Monitor your application for memory leaks.
Validate all input to your system very carefully, and reject all input that does not meet expectations.
Study the language you are using and make a list of unsafe and more-safe functions, then share that list with your entire team. If possible, add it to your secure coding guideline or standard. For example, in C, prefer strncpy() over strcpy() and strncat() over strcat().
If your language or framework offers memory safety libraries, use them. For example: Safestringlib or SafeStr.
Use managed buffers and strings rather than raw arrays and pointers whenever possible.
Take secure coding training that focuses on memory issues and/or your language of choice. Inform your trainer that you are concerned about memory management failures.
Perform code reviews and/or static analyses.
Use compiler tools that help with memory management such as StackShield, StackGuard, and Libsafe.
Perform fuzzing on every input to your system.
If you have a penetration test performed, inform your tester that you are concerned about memory management failures and that you would like them to pay special attention to this while testing.
Fix all compiler errors and warnings. Do not ignore warnings because your program compiles.
Ensure your underlying infrastructure is regularly patched, scanned, and hardened.
Monitor your underlying infrastructure specifically for potential memory vulnerabilities and other failures.
Consider using canaries to protect your address stack from overflow attacks.

Example attack scenarios.

Scenario #1: Buffer overflows are the most famous memory vulnerability, a situation where an attacker submits more information into a field than it can accept, such that it overflows the buffer created for the underlying variable. In a successful attack, the overflow characters overwrite the stack pointer, allowing the attacker to insert malicious instructions into your program.

Scenario #2: Use-After-Free (UAF) happens often enough that it’s a semi-common browser bug bounty submission. Imagine a web browser processing JavaScript that manipulates DOM elements. The attacker crafts a JavaScript payload that creates an object (such as a DOM element) and obtains references to it. Through careful manipulation, they trigger the browser to free the object's memory while keeping a dangling pointer to it. Before the browser realizes the memory has been freed, the attacker allocates a new object that occupies the same memory space. When the browser tries to use the original pointer, it now points to attacker-controlled data. If this pointer was for a virtual function table, the attacker can redirect code execution to their payload.

Scenario #3: A network service that accepts user input, doesn’t properly validate or sanitize it, then passes it directly to the logging function. The input from the user is passed to the logging function as syslog(user_input) instead of syslog("%s", user_input), which doesn’t specify the format. The attacker sends malicious payloads containing format specifiers such as %x to read stack memory (sensitive data disclosure) or %n to write to memory addresses. By chaining together multiple format specifiers they could map out the stack, locate important addresses, and then overwrite them. This would be a Format string vulnerability (uncontrolled string format).

Note: modern browsers use many levels of defenses to defend against such attacks, including browser sandboxing ASLR, DEP/NX, RELRO, and PIE. A memory management failure attack on a browser is not a simple attack to carry out.