Fix API Rate Limit Exhaustion in Quarkus

Rate limit exhaustion in Quarkus applications is a critical vulnerability that allows attackers to perform Denial of Service (DoS) attacks, brute-force credentials, or scrape sensitive data by flooding endpoints. Without explicit throttling, the Netty event loop or worker threads can be saturated, leading to service-wide unavailability. Fixing this requires shifting from 'open-by-default' to a controlled token-bucket or fixed-window strategy.

The Vulnerable Pattern

@Path("/api/v1/heavy-resource")
public class InsecureResource {
@GET
@Produces(MediaType.APPLICATION_JSON)
public Response getData() {
    // VULNERABILITY: No throttling mechanism.
    // An attacker can script thousands of concurrent requests,
    // exhausting DB connections or CPU cycles.
    return Response.ok(heavyService.compute()).build();
}
}

The Secure Implementation

The fix utilizes the SmallRye Fault Tolerance extension. By applying the @RateLimit annotation, we define a maximum throughput (value) within a specific timeframe (window). This prevents resource starvation by shedding load at the application boundary. For production-grade hardening, integrate this with a Redis-backed rate limiter or an API Gateway (like Kong or Traefik) to handle distributed rate limiting across multiple pod instances, as the local annotation tracks state per-node.

import io.smallrye.faulttolerance.api.RateLimit;
import java.time.temporal.ChronoUnit;
@Path(“/api/v1/heavy-resource”)
public class SecureResource {
@GET
@RateLimit(value = 10, window = 1, windowUnit = ChronoUnit.MINUTES)
@Produces(MediaType.APPLICATION_JSON)
public Response getData() {
    // SECURE: SmallRye Fault Tolerance enforces a limit of 10 requests per minute.
    // Excess requests automatically trigger a 429 Too Many Requests response.
    return Response.ok(heavyService.compute()).build();
}
}