Fix Unrestricted Resource Consumption in Micronaut

Unrestricted resource consumption (CWE-400) in Micronaut occurs when endpoints lack constraints on memory, CPU, or file descriptors. Attackers can trigger Out of Memory (OOM) errors or thread pool exhaustion by sending massive payloads or holding connections open. In Micronaut, this usually manifests through default Netty configurations that are too permissive or by blocking the Event Loop with heavy tasks.

The Vulnerable Pattern

@Controller("/api")
public class ResourceLeakController {
    @Post(value = "/process", consumes = MediaType.APPLICATION_OCTET_STREAM)
    public String processData(@Body byte[] data) {
        // VULNERABILITY: No limit on request body size.
        // Attacker sends 10GB payload, JVM crashes with OutOfMemoryError.
        // Also, processing large arrays on the Netty Event Loop blocks all other requests.
        return "Processed " + data.length + " bytes";
    }
}

The Secure Implementation

To mitigate resource exhaustion, you must apply a multi-layered defense. First, hard-cap the 'micronaut.server.max-request-size' in your configuration to prevent heap-spraying via large POST bodies. Second, use the '@ExecuteOn(TaskExecutors.IO)' annotation for any endpoint handling significant data; this prevents the Netty Event Loop from stalling, which would otherwise lead to a Denial of Service for the entire application. Finally, configure Netty's worker thread counts and connection timeouts to prevent 'Slowloris' style attacks where attackers hold connections open to exhaust the file descriptor limit.

micronaut:
  server:
    max-request-size: 1MB
    netty:
      max-chunk-size: 8KB
      worker:
        threads: 16
@Controller(“/api”)
public class SecureController {
@Post(value = “/process”, consumes = MediaType.APPLICATION_OCTET_STREAM)
@ExecuteOn(TaskExecutors.IO)
public HttpResponse processData(@Body byte[] data) {
// FIX: max-request-size in application.yml enforces limits at the Netty level.
// FIX: @ExecuteOn(TaskExecutors.IO) offloads processing to a dedicated thread pool.
return HttpResponse.ok(“Processed securely”);
}
}