Fix Lack of Resources & Rate Limiting in Qwik

Qwik's resumability architecture optimizes delivery, but it doesn't inherently protect your server-side logic from resource exhaustion. Without explicit rate limiting on `routeAction$` and `routeLoader$` functions, an attacker can trigger expensive DB queries or CPU-intensive operations repeatedly, leading to a Denial of Service (DoS). In a QwikCity environment, you must enforce limits at the entry point of your server-side logic or via middleware.

The Vulnerable Pattern

import { routeAction$ } from '@builder.io/qwik-city';
// VULNERABLE: No protection against automated spamming
export const useSubmitData = routeAction$(async (data) => {
// Expensive operation triggered by any POST request
const result = await db.complexAggregation(data.userId);
return result;
});

The Secure Implementation

The vulnerability lies in the lack of request throttling on server-side actions. The secure implementation introduces a rate-limiting layer using `rate-limiter-flexible` (or similar Redis-backed stores for distributed environments). We extract the client IP from the request headers and attempt to consume a 'point'. If the threshold is exceeded, we immediately return a 429 status code using Qwik's `fail` utility, preventing the expensive `db.complexAggregation` from executing. For production, always use a distributed store like Redis instead of in-memory storage to handle multiple server instances.

import { routeAction$, fail } from '@builder.io/qwik-city';
import { RateLimiterMemory } from 'rate-limiter-flexible';
const opts = { points: 5, duration: 60 }; // 5 requests per minute
const rateLimiter = new RateLimiterMemory(opts);
export const useSubmitData = routeAction$(async (data, { request, status }) => {
const ip = request.headers.get(‘x-forwarded-for’) || ‘anonymous’;
try {
await rateLimiter.consume(ip);
} catch (rejRes) {
return fail(429, { message: ‘Too many requests. Slow down, hacker.’ });
}
const result = await db.complexAggregation(data.userId);
return result;
});