Cloudflare Rate Limiting y WAF: Detén Denial of Wallet

Nueva amenaza en la era serverless: Denial of Wallet (Denegación de Cartera)

En los entornos tradicionales on-premise o de servidores virtuales (EC2/Compute Engine), cuando se sufre un ataque DDoS (Distributed Denial of Service), la CPU del servidor alcanza el 100% y el servicio se cae. Esto se conocía como ataque de denegación de servicio (Denial of Service).

Sin embargo, en entornos serverless y de edge computing de pago por uso (AWS Lambda, Vercel, Supabase, Cloudflare Workers) y API de LLM (OpenAI, Anthropic Claude), si se produce un ataque DDoS o una ráfaga indiscriminada de bots scrapers maliciosos, en lugar de que el servicio se caiga, surge una enorme factura de infraestructura.

Este es el Denial of Wallet (DoW, Denegación de Cartera), la amenaza más crítica en la seguridad de la nube moderna.

[Casos de daño por Denial of Wallet (a fecha de 2026)]
- Un desarrollador publica una API para un proyecto personal / startup (Vercel + Supabase / Lambda + OpenAI API)
- Una red de bots maliciosos genera un tráfico de 100,000 llamadas API por minuto
- Resultado: En un solo día se genera un cobro automático de $5,000~$12,000 (aprox. 7 a 16 millones de KRW)

Anteriormente, para mitigar estos ataques continuos, se implementaba el Rate Limiting (limitación de tráfico) manualmente acumulando contadores de solicitudes en un Redis externo (Upstash, Redis ElastiCache) o en Workers KV.

Sin embargo, este enfoque presentaba dos grandes limitaciones: (1) latencia de red de 10ms~30ms al consultar Redis, y (2) costos adicionales de infraestructura por las tarifas de lectura y escritura en Redis.

Al combinar la Cloudflare Native Workers Rate Limiting API (binding ratelimits), que alcanzó el estado GA (Generally Available) oficial en septiembre de 2025, con Cloudflare Edge WAF (Web Application Firewall), es posible construir un escudo de defensa edge en 3 capas perfecto, con $0 de costo de infraestructura adicional y 0ms de latencia.

En este artículo se abordan en detalle desde el mecanismo de Denial of Wallet hasta la implementación de Cloudflare Native Rate Limiting API (env.RATE_LIMITER), la configuración de reglas de WAF Edge, la integración con el middleware Hono.js y los benchmarks de defensa frente a ataques reales.

Redis Rate Limiting vs Cloudflare Native Rate Limiting API

Arquitectura de defensa Edge jerárquica en 3 capas (Layered Edge Defense)

Para bloquear por completo las facturas sorpresa en la nube, es necesario construir una línea de defensa estructurada en 3 capas.

+-----------------------------------------------------------------------------------+
| Pipeline de defensa Edge en 3 capas de Cloudflare (Layered Edge Defense)          |
+-----------------------------------------------------------------------------------+

[Tráfico de bots maliciosos DDoS / Scrapers]
         |
         v
 [Layer 1: Cloudflare Edge WAF Rules] ------------> (Bloqueo automático en 0.1ms antes de ejecutar el Worker / Consumo de $0)
         | (Pasan solo IP / paquetes legítimos)
         v
 [Layer 2: Native Worker Rate Limiting API] ------> (env.RATE_LIMITER: Límite de 100 req/min por IP/usuario)
         | (Devuelve HTTP 429 Too Many Requests de inmediato)
         v
 [Layer 3: Cloudflare Turnstile] -----------------> (Verificación de bloqueo de bots sin CAPTCHA)
         |
         v
 [Lógica de backend protegida / D1 DB / OpenAI API] (Ejecución segura)

1. Layer 1 (Cloudflare Edge WAF): Bloquea redes de bots maliciosas o rangos de IP de spam conocidos en los nodos edge antes de que el código del Worker se ejecute (reduce el número de ejecuciones del Worker a 0, logrando un costo de $0).
2. Layer 2 (Native Workers Rate Limiting API): Identifica a los usuarios legítimos pero que envían demasiadas solicitudes en poco tiempo (según IP, API Key o User ID) mediante env.RATE_LIMITER.limit({ key }) por minuto/segundo y devuelve HTTP 429 Too Many Requests.
3. Layer 3 (Cloudflare Turnstile): Filtra por completo los bots mediante una verificación invisible de patrones biométricos y de comportamiento al enviar formularios importantes (registro, pago, solicitudes de prompts LLM).

Paso 1: Declaración de Native Rate Limiting en wrangler.jsonc

Se declara el binding ratelimits de Cloudflare Workers.

// wrangler.jsonc
{
  "$schema": "node_modules/wrangler/config-schema.json",
  "name": "edge-dow-defense",
  "main": "src/index.ts",
  "compatibility_date": "2026-01-01",
  "compatibility_flags": ["nodejs_compat"],

  // Declaración del binding de Native Rate Limiting oficial GA en 2025/2026
  "ratelimits": [
    {
      "binding": "API_RATE_LIMITER",
      "namespace_id": "1001", // ID de namespace único dentro de la cuenta
      "simple": {
        "limit": 60,         // Número máximo de solicitudes permitidas
        "period": 60          // Ventana de tiempo (en segundos: permite 60 solicitudes en 60 segundos)
      }
    },
    {
      "binding": "STRICT_AUTH_LIMITER",
      "namespace_id": "1002",
      "simple": {
        "limit": 5,          // Intentos de login/contraseña: permite solo 5 solicitudes en 60 segundos
        "period": 60
      }
    }
  ]
}

Paso 2: Construcción de middleware serverless con Hono.js

Se construye el middleware que integra la Native Rate Limiting API en el punto de entrada de la aplicación Worker.

Código práctico de src/index.ts

// src/index.ts
import { Hono } from "hono";
import { cors } from "hono/cors";

type Env = {
  Bindings: {
    API_RATE_LIMITER: RateLimiter;
    STRICT_AUTH_LIMITER: RateLimiter;
  };
};

const app = new Hono<Env>();

app.use("*", cors());

// -------------------------------------------------------------------
// 1. Middleware de Native Rate Limiting global basado en IP (Layer 2)
// -------------------------------------------------------------------
app.use("/api/*", async (c, next) => {
  // Extraer la IP real del cliente desde las cabeceras de Cloudflare Edge
  const clientIP = c.req.header("cf-connecting-ip") || "anonymous";

  // Ejecución de Native Rate Limiter (¡latencia de 0ms!)
  const { success } = await c.env.API_RATE_LIMITER.limit({ key: clientIP });

  if (!success) {
    console.warn(`[DoW Defense] Rate limit exceeded for IP: ${clientIP}`);
    return c.json(
      {
        error: "Too Many Requests",
        message: "Límite de solicitudes superado. Reintente en 1 minuto.",
      },
      429,
      {
        "Retry-After": "60",
      }
    );
  }

  await next();
});

// -------------------------------------------------------------------
// 2. Rate Limiter dedicado para rutas estrictas de login/autenticación
// -------------------------------------------------------------------
app.post("/api/auth/login", async (c) => {
  const clientIP = c.req.header("cf-connecting-ip") || "anonymous";

  // Defensa contra ataques de fuerza bruta en inicio de sesión fallido (límite de 5 veces/minuto)
  const { success } = await c.env.STRICT_AUTH_LIMITER.limit({ key: `auth:${clientIP}` });

  if (!success) {
    return c.json(
      { error: "Auth Lockout", message: "Se ha superado el número de intentos de contraseña." },
      429
    );
  }

  // Ejecución de la lógica de verificación de contraseña de inicio de sesión...
  return c.json({ success: true, token: "jwt_token_sample" });
});

// -------------------------------------------------------------------
// 3. Rate Limiting personalizado basado en API Key / JWT del usuario
// -------------------------------------------------------------------
app.post("/api/v1/llm-generate", async (c) => {
  const authHeader = c.req.header("authorization") || "";
  const apiKey = authHeader.replace("Bearer ", "") || "guest";

  // Aplicación de límites por API Key en lugar de IP (throttling individual por usuario/cliente)
  const { success } = await c.env.API_RATE_LIMITER.limit({ key: `apikey:${apiKey}` });

  if (!success) {
    return c.json({ error: "API Key Rate Limit Exceeded" }, 429);
  }

  // Ejecución de llamadas costosas a las API de OpenAI / Claude (¡protegido!)
  return c.json({ response: "AI Generated Content" });
});

export default app;

Paso 3: Configuración de reglas de Cloudflare Edge WAF (Defensa Layer 1)

Aunque la Native Worker Rate Limiting API evita consultas costosas a bases de datos o llamadas a LLM dentro de la lógica del Worker, para bloquear la invocación misma del Worker es necesario usar Cloudflare Dashboard Edge WAF Custom Rules en paralelo.

Regla personalizada WAF 1: Bloqueo indiscriminado de bots (Threat Score)

(cf.threat_score gt 15 or http.request.version eq "HTTP/1.0") -> Block

Las solicitudes con una puntuación de amenaza (Threat Score) mayor a 15 o procedentes de bots HTTP/1.0 antiguos se bloquean inmediatamente antes de ejecutar el Worker.

Regla personalizada WAF 2: Bloqueo al superar 100 req/min en rutas API (Edge WAF Rate Limit)

1. En el panel de Cloudflare (Dashboard), seleccionar Security > WAF > Rate limiting rules
2. Nombre de la regla (Rule Name): Block API Abuse DoW
3. Expresión (Expression): (http.request.uri.path starts_with "/api/")
4. Tasa (Rate): 100 requests per 1 minute
5. Acción (Action): Block (Duración: 10 minutes)

Al aplicar esta regla WAF, las IP atacantes que superen las 100 solicitudes por minuto se descartan en solo 0.1ms en la red backbone global de Cloudflare sin siquiera llegar a ejecutar una instancia del Worker.

Benchmark: Métricas de costo y rendimiento ante un ataque indiscriminado de 100,000 solicitudes DDoS/scrapers

Informe comparativo de costos y rendimiento según la arquitectura de defensa durante un ataque de 100,000 paquetes maliciosos (Minute Attack).

Tabla comparativa de arquitecturas de defensa contra DoW

Conclusión: Protege tu bolsillo en la nube frente a ataques Denial of Wallet

La nube y la tecnología serverless han aportado una enorme comodidad de desarrollo y escalabilidad; sin embargo, una API pública sin medidas de seguridad puede convertirse en cualquier momento en el blanco de un ataque “Denial of Wallet” capaz de llevar a una empresa a la quiebra.

La combinación de la Native Workers Rate Limiting API (env.RATE_LIMITER) de Cloudflare con Edge WAF ofrece las siguientes ventajas extraordinarias:

1. Bloqueo del 100% de facturas desastrosas: Aplica throttling al tráfico justo antes de ejecutar consultas costosas a bases de datos, API de LLM o lógica de comunicación externa.
2. 0ms de latencia: Mantiene la experiencia de usuario (UX) más rápida gracias a la verificación edge in-process en V8 sin comunicarse con servidores Redis externos.
3. $0 de costo de infraestructura adicional: Resuelto con características integradas en el runtime de Cloudflare sin necesidad de almacenamiento ni suscripciones a servicios externos.
4. Seguridad edge jerárquica: Construye una línea de defensa triple invencible mediante WAF + Native Rate Limiter + Turnstile.

Aplica ahora mismo la Native Rate Limiting API en tus rutas de API backend y construye una arquitectura serverless 100% segura e inmutable frente a cualquier ataque de tráfico malicioso.

Artículo relacionado: En la Guía para construir autenticación por $0 con Cloudflare Workers + Passkey (WebAuthn) sin Auth0 ni Clerk también puedes consultar cómo implementar autenticación segura en el edge.