Rate limiting en aplicaciones web: qué proteger antes de elegir una librería

La solución correcta para proteger una ruta de Next.js contra abuso es no empezar por el middleware. Sé que suena raro — todo el mundo busca npm install upstash-ratelimit antes de pensar en qué está protegiendo. Pero esa secuencia garantiza que vas a poner el límite equivocado en el lugar equivocado.

Mi tesis es simple: rate limiting no es una dependencia; es una política de abuso. Y una política requiere decisiones antes de código.

Si alguna vez terminaste ajustando un threshold "a ojo" en producción porque los logs te mostraron falsos positivos, ya viviste este problema. Esta guía es para que no lo repitas.

Rate limiting aplicaciones web Next.js: el orden que casi nadie respeta

La secuencia típica es: leer un tutorial, copiar el middleware, tunear el número hasta que deje de haber quejas. Eso no es una política — es prueba y error sobre usuarios reales.

El orden que sí funciona empieza con cuatro preguntas antes de tocar código:

¿Qué activo protegés? Un endpoint de login no es lo mismo que una API pública de búsqueda, que no es lo mismo que un webhook entrante.
¿Qué abuso esperás? ¿Credential stuffing? ¿Scraping? ¿Un bot que llena formularios? El vector esperado determina el patrón de límite.
¿Cuánto cuesta un falso positivo? Si limitás de más en /api/auth/login, bloqueás usuarios legítimos. Si limitás de menos en /api/send-email, pagás por spam.
¿Cómo vas a observar que el límite está funcionando? Sin métricas, no hay política — hay esperanza.

OWASP lo plantea claramente en su Authentication Cheat Sheet: los controles defensivos alrededor de autenticación deben incluir lockout progresivo, logging de intentos y distinción entre errores por credencial vs. errores por throttle. No dice "instalá una librería". Dice "definí el comportamiento esperado y medilo".

Dónde se equivoca la gente: la receta copiada y su costo oculto

El pattern más común que veo en codebases Next.js es algo así:

// middleware.ts — el clásico "lo copié de la docs"
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  // 10 requests por 10 segundos — ¿por qué 10? "parecía razonable"
  limiter: Ratelimit.slidingWindow(10, "10 s"),
});

export async function middleware(request: NextRequest) {
  const ip = request.ip ?? "127.0.0.1";
  const { success } = await ratelimit.limit(ip);

  if (!success) {
    return NextResponse.json({ error: "Too Many Requests" }, { status: 429 });
  }
}

El código funciona. El problema no está en el código — está en lo que no está escrito:

Problema 1 — Límite global sin distinción de ruta. Un middleware aplicado a matcher: ["/((?!_next).*)", ] limita igual /api/auth/login que /api/products/search. Son activos con perfiles de abuso completamente distintos.

Problema 2 — IP como única clave. En Argentina (y en cualquier ISP con CGNAT), múltiples usuarios comparten la misma IP pública. Limitar por IP pura significa que el vecino del edificio puede hacerte un "accidental DDoS" a vos sin querer.

Problema 3 — Sin observabilidad. Si success = false devuelve 429 y no hay log, no sabés si estás bloqueando un bot o a tu propio usuario de prueba corriendo tests de integración.

Problema 4 — Sin costo diferencial. Bloquear una búsqueda de producto tiene costo bajo. Bloquear un intento de login legítimo después de un cambio de IP (trabajo → casa → VPN) tiene costo alto. El threshold no puede ser el mismo número.

Esto no es teórico. Es el patrón que aparece cuando buscás "Next.js rate limiting" en GitHub y mirás las primeras diez implementaciones. La mayoría comparten el mismo middleware sin política detrás.

La matriz de decisión: qué mirar antes de escribir una línea

Antes de elegir cualquier implementación — Upstash, express-rate-limit, tu propio contador en Redis o un WAF externo — completá esta matriz para cada endpoint que querés proteger:

┌─────────────────────────┬────────────────┬──────────────────┬────────────────────┬─────────────────────┐
│ Endpoint                │ Activo         │ Abuso esperado   │ Costo FP (falso+)  │ Granularidad clave  │
├─────────────────────────┼────────────────┼──────────────────┼────────────────────┼─────────────────────┤
│ /api/auth/login         │ Cuenta usuario │ Credential stuff │ ALTO — bloqueo real│ IP + username       │
│ /api/contact            │ Bandeja email  │ Spam masivo      │ MEDIO — UX dañada  │ IP + fingerprint    │
│ /api/search             │ BD pública     │ Scraping         │ BAJO — búsqueda    │ IP (con CGNAT warn) │
│ /api/webhooks/incoming  │ Pipeline datos │ Replay attack    │ BAJO — ignorar     │ API key + timestamp │
└─────────────────────────┴────────────────┴──────────────────┴────────────────────┴─────────────────────┘

La columna que más se ignora es Costo FP. Es la que determina si errás para adentro (demasiado permisivo) o para afuera (demasiado restrictivo) — y cuál de los dos es más tolerable para ese activo específico.

Para /api/auth/login, OWASP recomienda explícitamente estrategias de lockout progresivo con notificación al usuario, no un 429 silencioso. Eso requiere lógica de negocio, no solo middleware.

Implementación consciente: cómo se ve una política real en Next.js

Con la matriz en mano, el middleware cambia de forma:

// lib/rate-limit.ts — política explícita por activo
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";

const redis = Redis.fromEnv();

// Política diferenciada: cada constante documenta una decisión
export const loginRatelimit = new Ratelimit({
  redis,
  // 5 intentos por minuto por IP+username — basado en OWASP lockout guidance
  // Costo FP alto: preferimos falso negativo antes que bloquear usuario real
  limiter: Ratelimit.fixedWindow(5, "60 s"),
  analytics: true, // observabilidad habilitada — no negociable
});

export const searchRatelimit = new Ratelimit({
  redis,
  // 100 req/10s por IP — costo FP bajo, margen más ancho
  limiter: Ratelimit.slidingWindow(100, "10 s"),
  analytics: true,
});

// app/api/auth/login/route.ts — política aplicada con contexto
import { loginRatelimit } from "@/lib/rate-limit";
import { NextRequest, NextResponse } from "next/server";

export async function POST(request: NextRequest) {
  const body = await request.json();
  const username = body?.username ?? "anon";
  const ip = request.ip ?? "unknown";

  // Clave compuesta: IP + username evita el problema de CGNAT
  // Un usuario en CGNAT compartido no afecta a otros usuarios distintos
  const identifier = `login:${ip}:${username}`;

  const { success, limit, remaining, reset } = await loginRatelimit.limit(identifier);

  if (!success) {
    // Log explícito: sin esto no hay política, hay esperanza
    console.warn(`[rate-limit] LOGIN bloqueado — identifier: ${identifier}, reset: ${reset}`);

    return NextResponse.json(
      {
        error: "Demasiados intentos. Intentá nuevamente en unos minutos.",
        // No exponer reset exacto en producción — información útil para atacantes
      },
      {
        status: 429,
        headers: {
          "Retry-After": String(Math.ceil((reset - Date.now()) / 1000)),
        },
      }
    );
  }

  // ... lógica de autenticación
}

Dos diferencias críticas respecto al middleware genérico: la clave es compuesta (no solo IP) y cada rechazo genera un log. Sin log, no hay feedback para ajustar la política.

Si usás Railway para deployar — que es mi stack actual para proyectos Next.js — los logs del console.warn van directo al dashboard de Railway sin configuración extra. Es suficiente para empezar a ver patrones antes de necesitar algo más sofisticado.

Límites de esta guía: qué no podés concluir sin tus propios datos

Esto es importante y no lo voy a enterrar al final: los números de esta guía son puntos de partida, no valores validados para tu caso.

No sabés si 5 intentos por minuto es el threshold correcto para login hasta que:

Medís la distribución real de intentos de usuarios legítimos en tu app (un usuario que olvidó la contraseña puede intentar 3-4 veces en 30 segundos)
Observás cuántos 429 genera el límite en la primera semana
Revisás si hay tests de integración o health checks que disparen el mismo endpoint

Sin esos datos, cualquier número que elijas — incluyendo los de este post — es una estimación educada. El objetivo del post no es darte el threshold; es que sepas qué preguntas hacerte antes de fijarlo.

Lo mismo aplica para la elección de librería. Upstash funciona bien con Next.js en Edge Runtime porque Redis opera fuera del bundle. Pero si ya tenés Redis propio en Railway, un wrapper simple con ioredis puede ser suficiente. La decisión depende de tu infraestructura, no de un benchmark universal.

Si te interesa cómo conectar observabilidad más profunda en Next.js, el post de OpenTelemetry en Spring Boot donde los logs dicen OK y los traces muestran el problema tiene el mismo principio: sin traza, el diagnóstico es adivinanza.

Errores comunes que convierten una política en ruido

Error 1 — Rate limiting sin header Retry-After. RFC 6585 especifica que un 429 debería incluir Retry-After. Sin él, el cliente (o el browser) puede reintentar inmediatamente y amplificar la carga. Ya cubrí este patrón en el post de Retry no es gratis: el costo del reintento no aparece en el p95 hasta que ya es tarde.

Error 2 — Aplicar rate limiting en el cliente. Veo esto ocasionalmente: throttle en el frontend para "no sobrecargar la API". El cliente no es una frontera de seguridad. Cualquier persona con curl la saltea.

Error 3 — Confundir rate limiting con autenticación. Un límite de 429 no reemplaza validación de credenciales, tokens ni autorización. Reduce la superficie de ataque en el tiempo, pero no autentica nada. Son capas distintas, no alternativas.

Error 4 — Ignorar el efecto de CDN/proxy. Si tu Next.js está detrás de Vercel Edge, Cloudflare o un nginx, request.ip puede devolver la IP del proxy, no del cliente real. Necesitás leer X-Forwarded-For con cuidado — y validar que el header no pueda ser falsificado desde el cliente.

// Extraer IP real con conciencia del stack
function getClientIp(request: NextRequest): string {
  // X-Forwarded-For puede tener múltiples valores: "client, proxy1, proxy2"
  // El primero es el cliente real — pero solo si confiás en el proxy que lo setea
  const forwarded = request.headers.get("x-forwarded-for");
  if (forwarded) {
    return forwarded.split(",")[0].trim();
  }
  return request.ip ?? "unknown";
}

FAQ: preguntas reales sobre rate limiting en Next.js

¿Necesito Redis para rate limiting en Next.js?
No para casos simples, pero sí para cualquier deploy con más de una instancia. En-memoria no funciona cuando hay múltiples réplicas porque cada instancia tiene su propio contador. Si usás Railway con un solo container, en-memoria puede alcanzar para empezar — pero es una deuda técnica visible.

¿Cuál es la diferencia entre rate limiting y throttling?
Rate limiting rechaza requests que superan un umbral (429 Too Many Requests). Throttling los encola o los ralentiza sin rechazarlos. Para protección contra abuso, rate limiting es más predecible. Throttling tiene su lugar en colas de procesamiento, no en APIs públicas.

¿Debo poner el rate limiting en middleware o en cada route handler?
Depende de la granularidad que necesitás. Middleware global es conveniente pero aplica la misma política a todo. Route handler te da control fino por activo. La matriz de decisión de más arriba debería guiar esa elección — si todos tus activos tienen el mismo perfil de abuso, el middleware está bien.

¿Qué pasa con los bots que rotan IPs?
IP-based rate limiting sola no alcanza contra bots sofisticados con rotación de IP. Para ese vector, necesitás fingerprinting de browser (TLS JA3, user-agent patterns, behavior analysis) o un WAF dedicado. Es un scope diferente al de este post — y honestamente, si llegaste a ese problema, necesitás más que una librería de Node.

¿Upstash Ratelimit es la única opción para Next.js en Edge Runtime?
No. Upstash funciona bien porque su cliente Redis es HTTP-based y compatible con Edge. Pero también podés usar @vercel/kv si estás en Vercel, o un worker de Cloudflare con KV si usás Cloudflare Workers. La restricción técnica es que Edge Runtime no soporta sockets TCP — cualquier solución tiene que hablar HTTP para el almacenamiento.

¿Cómo sé si mi rate limit está bien calibrado?
Mirá la distribución de 429 en los primeros 7 días de activación. Si los 429 vienen de IPs/identificadores únicos que nunca viste antes → el límite está capturando abuso. Si los 429 vienen de IPs recurrentes que también tienen requests exitosos → posible falso positivo. Sin analytics activado en la librería y sin logs, no podés responder esta pregunta.

Mi postura: la librería es un detalle de implementación

Rate limiting en aplicaciones web con Next.js es un tema donde el 80% del trabajo es decisión técnica y el 20% es código. Casi toda la literatura hace lo inverso.

No compro el argumento de que "cualquier rate limiting es mejor que ninguno". Un límite mal calibrado sobre un endpoint de login puede bloquear usuarios legítimos de forma sistemática — y ese daño es medible y silencioso si no tenés observabilidad.

Lo que sí compro: definir la política antes del código obliga a hacerse preguntas que el middleware genérico no te hace. ¿Qué activo? ¿Qué abuso? ¿Qué costo si me equivoco para afuera? Esas tres preguntas cambian el threshold, la granularidad de la clave y el comportamiento ante el rechazo.

El próximo paso concreto: tomá el endpoint más crítico de tu app (probablemente login o registro), completá la fila de la matriz para ese activo, y recién ahí escribí el límite. Si querés ver cómo aplicar el mismo pensamiento a Server Actions con Prisma, el post de Prisma Server Actions en Next.js y el N+1 que aparece cuando no lo esperás tiene el mismo patrón: diagnóstico antes de solución.

Y si el endpoint que protegés maneja datos sensibles, el post sobre useEffect y sincronización de estado en React 19 es un recordatorio de que las abstracciones que simplifican también pueden esconder comportamiento inesperado — aplica igual para middleware.

Fuente original: