Resource Allocation Without Limits

This is CWE-770, closely related to the broader uncontrolled-resource-consumption category but narrower in a useful way: it's specifically about an allocation step, memory, file handles, threads, database connections, or storage, that happens with no upper bound tied to it. A single request that triggers one unbounded allocation (accepting an arbitrarily large file upload with no size cap, opening a new database connection per request with no pool limit, spawning a thread per incoming connection with no cap on concurrency) is enough on its own to let one client exhaust a resource that's meant to be shared across everyone. The distinction from the broader DoS/resource-exhaustion category is really about where the fix lives: this is about a missing ceiling on a specific allocation call, not about an expensive computation (like a slow regex) taking too long to run.

• File upload endpoints with no maximum size enforced
• Database connection handling with no pool size limit, letting a burst of requests exhaust available connections
• Endpoints that allocate a new resource (a thread, a temporary file, a cache entry) per request with no cap on how many can exist concurrently

• Submit progressively larger file uploads and observe whether the server enforces any maximum size, capping the test at a safe ceiling rather than actually exhausting server resources
• Fire a burst of concurrent requests against an endpoint suspected of allocating a resource per request (a connection, a thread, a session) and observe whether the server degrades or refuses new requests once a real limit is hit, or keeps accepting indefinitely
• Submit a request designed to create an unusually large number of small allocations at once (many form fields, a deeply structured payload) rather than one large one

• Progressively larger file uploads (1MB, 10MB, 50MB), capped well short of anything that would actually degrade the target
• A burst of concurrent requests to a single endpoint, sized to reveal whether a connection or resource pool has any enforced limit

Testing here needs to stay firmly on the safe side: the goal is to demonstrate the absence of a limit, not to actually exhaust the resource in question against a real target. Submitting progressively larger inputs capped at a safe ceiling, and watching whether the server ever pushes back with a size-limit error before that ceiling, answers the question without causing real damage. For allocation-per-request patterns, a moderate concurrent burst that would reveal a real limit if one exists, without being large enough to constitute an actual denial-of-service attempt, is the right scale to test at.

Tip: Testing tools that run these checks in parallel across every discovered endpoint can cut the time required substantially compared to fully manual testing, as long as they confirm findings with more than one signal to keep the false-positive rate down.

• A server accepting inputs larger than expected but still well within reasonable bounds isn't necessarily missing a limit, some limits are simply set generously.
• The finding requires showing that no limit is enforced at all, or that the enforced limit is unreasonably high relative to the resource's cost, not just that a specific test size happened to succeed.

Manual Testing Methodology

Here is a systematic approach to identifying Resource Allocation Without Limits vulnerabilities in a target application.

Before testing, map all input vectors that could be affected. Identify parameters, headers, cookies, and request bodies that interact with the vulnerable component. A proxy such as Burp Suite or OWASP ZAP, paired with normal browsing of the target, is usually enough to build this list.

Send a legitimate request and record the normal response: status code, content length, response time, and any identifying tokens. This baseline matters because it's what you'll compare later responses against once payloads are involved.

Inject test payloads into each identified input vector one at a time. Start with benign detection payloads before escalating to anything that could actually trigger the vulnerability. For Resource Allocation Without Limits specifically, send a burst of requests against the target endpoint (login, password reset, MFA code, or a pagination/size-controlled parameter) well beyond what a legitimate user would generate in the same window, from both a single IP and, where feasible, multiple sources.

Compare the response against your baseline, looking specifically for whether the request volume is accepted without throttling, delay, or lockout — and separately, whether resource-controlling parameters (page size, requested item count) can be set high enough to measurably degrade response time or server load.

Once a potential vulnerability is detected, confirm it with at least a few independent test cases to rule out coincidence. Document the exact request and response as proof. For Resource Allocation Without Limits, a confirmed finding typically means showing that attacker-controlled input changes the application's behavior in a way that matters for security, not just that a payload was reflected somewhere harmless.

Real-World Impact

Missing rate limiting on authentication and other sensitive endpoints turns what should be a slow, detectable attack into a fast, automatable one. Without a cap on attempts, credential stuffing and password-spraying campaigns can run at whatever speed the attacker's infrastructure allows, and password-reset or MFA-code endpoints without a limit become brute-forceable in a realistic timeframe.

The same underlying gap — no bound on how much of a resource a single request or account can consume — also enables denial-of-service through resource exhaustion: unbounded pagination, unbounded file-processing size, or unbounded concurrent request creation can degrade or take down a service without needing a "real" logic vulnerability at all.

This class of finding is frequently underrated relative to its actual risk, since a single unrated request looks harmless — the impact only becomes obvious once it's run at scale, which is exactly what an attacker will do.

Prevention and Secure Coding

Preventing Resource Allocation Without Limits takes a defense-in-depth approach — no single control below is sufficient alone, but together they close off both the primary path and the most common bypasses.

Rate-limit per account and per IP. Apply limits on both axes for authentication, password-reset, and MFA-code endpoints — per-IP alone is defeated by distributed sources, and per-account alone is defeated by targeting many accounts slowly.

Progressive lockout, not a hard ceiling alone. Increasing delays or temporary lockouts after repeated failures slow an attacker meaningfully without permanently locking out a legitimate user who mistyped a password a few times.

CAPTCHA or proof-of-work after a threshold. Add friction after a small number of failures rather than either allowing unlimited attempts or blocking outright, which balances usability against abuse.

Explicit resource limits everywhere, not just login. Cap pagination size, upload size, and any operation whose cost scales with a client-supplied number, so a single request can't consume disproportionate server resources.