Fix Lack of Resources & Rate Limiting in Micronaut

Micronaut's default configuration is built for speed, not defense. Without explicit rate limiting, an attacker can flood intensive endpoints—like bcrypt-heavy logins or complex DB queries—to trigger thread pool exhaustion and DoS. If you aren't intercepting the request pipeline to enforce quotas, your service is a sitting duck for resource depletion attacks.

The Vulnerable Pattern

@Controller("/api/v1")
public class DataController {
    @Post("/heavy-task")
    public HttpResponse processData(@Body String data) {
        // Vulnerable: No throttling. Attacker can spam this 10k times/sec
        // leading to CPU spikes and memory exhaustion.
        simulateComplexProcessing(data);
        return HttpResponse.ok("Processed");
    }
}

The Secure Implementation

The secure implementation utilizes a Micronaut `HttpServerFilter` combined with the Bucket4j library to enforce a Token Bucket algorithm. This intercepts every request to the specified path before it hits the controller. If the bucket is empty (limit reached), it short-circuits the request and returns a 429 'Too Many Requests' status, preventing downstream resource consumption. In a production environment, you should extend this to use a `ProxyManager` with Redis to track limits across multiple instances and identify users by API keys or IP addresses rather than a global bucket.

@Filter("/api/v1/**")
public class RateLimiterFilter implements HttpServerFilter {
    private final Bucket bucket = Bucket.builder()
        .addLimit(Bandwidth.classic(10, Refill.intervally(10, Duration.ofMinutes(1))))
        .build();
@Override
public Publisher<MutableHttpResponse<?>> doFilter(HttpRequest<?> request, ServerFilterChain chain) {
    if (bucket.tryConsume(1)) {
        return chain.proceed(request);
    }
    return Publishers.just(HttpResponse.status(HttpStatus.TOO_MANY_REQUESTS)
                     .header("Retry-After", "60"));
}
}