La versión corta

Si tienes una API pública pequeña y quieres mantenerla viva sin contratar un equipo de seguridad, elige un esquema de rate limiting que se parezca al tráfico que realmente tienes, no al peor caso que puedas imaginar.

Para la mayoría de las APIs independientes, un punto de partida razonable se ve así:

  • Clasifica los límites por API key para tráfico autenticado, con un respaldo por IP en rutas sin autenticación.
  • Usa token bucket como algoritmo por defecto. Da un comportamiento suave y permite ráfagas cortas sin que esas ráfagas se coman todo tu presupuesto.
  • Aplica los límites en el borde — tu API gateway, proxy inverso o un servicio gestionado — para que una mala petición nunca llegue a tu servidor de aplicación.
  • Empieza con un límite global por clave y límites más estrictos en los endpoints costosos. Añade un techo por tenant solo cuando realmente tengas clientes de pago compartiendo una cuenta.

Eso basta para detener los modos de falla habituales: credenciales filtradas, scripts desbocados y un cliente que acapara tu base de datos. Todo lo demás es optimización.

Por qué esto importa para una API pequeña

La razón por la que el rate limiting se siente urgente no es una teoría abstracta de seguridad. Es el costo realista de operar un producto pequeño con un endpoint público. Un solo script que se porta mal, una API key filtrada en un repositorio público o un pico repentino de un socio integrador pueden saturar tu backend, inflar tu factura en la nube o elevar los tiempos de respuesta lo suficiente como para que cualquier otro cliente lo perciba.

El rate limiting es también la capa que convierte tu API de un terreno sin reglas a un producto con contrato. Una vez que existe un límite, puedes decirle a un cliente “usaste tu cuota” en lugar de que tu servidor muera en silencio. OWASP lista el consumo irrestricto de recursos como uno de los riesgos estándar de las APIs, y la mitigación práctica es exactamente el tipo de límite que estás a punto de diseñar.

Paso 1: decide qué cuentas — IP, clave o tenant

La primera pregunta que responde cada limiter es quién cuenta. Las opciones habituales, en orden aproximado de confianza:

  • Por IP. La única señal que tienes antes de autenticar. Es la clave correcta para endpoints sin autenticación como registro, login, recuperación de contraseña y búsqueda pública. Su debilidad es conocida: una oficina corporativa, un operador móvil o una VPN pueden enrutar a miles de usuarios reales por una sola dirección, y una botnet puede enrutar millones de usuarios falsos.
  • Por API key. El estándar para cualquier endpoint autenticado. Los clientes rotan sus claves sin perder presupuesto y puedes ligar límites más altos a planes más caros.
  • Por usuario o cuenta. Útil cuando un cliente tiene muchas claves — por ejemplo, una agencia que emite una clave por cliente bajo una sola cuenta de facturación — y quieres limitar el uso agregado por organización.
  • Combinado. La mayoría de las APIs pequeñas terminan con un enfoque por capas: por IP en el borde sin autenticación, por clave en todo lo demás, con un techo por tenant como red de seguridad.

Una regla práctica: si la petición trae una API key válida, prefiere clasificar por clave. Recurre a IP solo cuando no haya clave, o como segunda capa para detectar una clave robada y compartida.

Paso 2: elige un algoritmo — ventana fija, ventana deslizante o token bucket

Todos los algoritmos de rate limiting responden la misma pregunta — cuántas peticiones ha hecho este cliente recientemente — con distintos compromisos.

  • Ventana fija. Cuentas peticiones en bloques discretos de tiempo (por minuto, por hora). Barata de implementar, fácil de razonar y el valor por defecto en la mayoría de gateways gestionados. La falla conocida es la ráfaga en el borde: un cliente puede enviar el tráfico equivalente a un minuto entero en el segundo 59 y otro minuto entero en el segundo 60, duplicando el techo previsto en la frontera. Para la mayoría de APIs pequeñas esto es aceptable.
  • Ventana deslizante. Una prima más precisa que pondera la ventana anterior para suavizar el problema del borde. Un poco más de estado que guardar, un poco más de costo para calcular. Vale la pena cuando ya tienes clientes de pago que notan la inequidad.
  • Token bucket. Imagina un balde que se llena a ritmo constante y se vacía un token por petición. Cuando el balde está vacío, las peticiones se rechazan. Es el algoritmo que describe Stripe en su propia publicación de ingeniería, y la razón es el comportamiento: puedes permitir una ráfaga generosa hasta el tamaño del balde mientras sigues respetando un promedio de largo plazo. Es un buen valor por defecto cuando el tráfico es desigual.

Para una primera versión, ventana fija en un gateway gestionado está bien. Sube a token bucket cuando tengas un endpoint costoso y quieras que las ráfagas en las rutas baratas no se coman el presupuesto de las caras.

Paso 3: decide los números

No existe un límite universal “correcto” y cualquier número específico que publiques debe probarse contra tu propio tráfico. Aun así, la forma de una política inicial sensata es bastante consistente en APIs pequeñas:

  • Un límite global generoso por clave — suficiente para que el comportamiento normal del cliente nunca lo note.
  • Un límite más estricto en el endpoint o los dos endpoints costosos — una ruta de búsqueda, una llamada a un LLM, un render de PDF, cualquier cosa que toque tu CPU o un tercero de pago.
  • Un límite más estricto por IP en endpoints sin autenticación — suficiente para frenar fuerza bruta y credential stuffing, no tan bajo que una conexión de oficina inestable quede bloqueada.

Dos cosas para tener presentes. Primero, trata el límite como un máximo al que tu cliente debería acercarse, no como un objetivo — la documentación de la API de Stripe es explícita en esto y se generaliza. Segundo, deja margen para subir límites más adelante. Es mucho más fácil relajar un límite que explicarle a un cliente de pago por qué su integración se rompió de un día para otro.

Paso 4: elige dónde aplicarlo

El punto de aplicación importa tanto como el algoritmo. La jerarquía general, de más barato a más flexible:

  1. Capa de borde y CDN. La mayoría de los API gateways gestionados y proxies inversos traen rate limiting integrado, y la mayoría de los CDNs importantes incluyen un motor de reglas que puede hacerlo. La ventaja es que una petición bloqueada nunca llega a tu origen, lo que protege directamente tu factura de cómputo. La desventaja es que la política vive en otro sistema y necesitas versionarla con cuidado.
  2. Middleware en la aplicación. Una librería dentro de tu servicio. Más flexible, más fácil de probar, pero cada petición rechazada ya consumió algo de cómputo para ser procesada.
  3. Un servicio dedicado de rate limiting respaldado por un almacén rápido. Es el enfoque estilo Stripe: un almacén en memoria (comúnmente Redis) compartido entre los servidores de aplicación para que el límite sea consistente sin importar qué servidor atienda la petición. Es la respuesta correcta cuando ya corres más de una instancia y necesitas que el conteo sea exacto entre ellas.

Para una API independiente, la ruta más barata que de verdad funciona casi siempre es el gateway. Añade un servicio dedicado solo cuando hayas superado lo que el gateway puede hacer.

Paso 5: dile al cliente qué pasó

Un límite solo sirve si el cliente puede reaccionar. Las señales estándar:

  • HTTP 429 para “superaste el límite, reduce la velocidad.”
  • Un cuerpo de mensaje claro que explique qué límite se alcanzó, no solo un error opaco.
  • Encabezados que digan al cliente cuántas peticiones le quedan y cuándo se reinicia la ventana, para que los clientes bien portados puedan auto-regularse.

Si publicas una API, documenta los encabezados. Muchos SDK ya entienden el 429 y un reintento con backoff exponencial es el valor por defecto educado.

Qué significa realmente “justo” en una API pequeña

La equidad es la parte que nadie quiere definir. Una definición funcional para un producto independiente: cada cliente de pago recibe la holgura que promete su plan, los usuarios del tier gratuito reciben un presupuesto que no interfiere con el tráfico de pago, y el tráfico abusivo se descarta antes de que te cueste dinero. Todo lo demás es detalle.

Las señales prácticas de que tus límites son injustos: clientes de pago se quejan de 429 en uso normal, el tráfico del tier gratuito degrada los tiempos de respuesta del tier de pago, o tu analítica muestra una clave consumiendo una proporción desproporcionada de peticiones. Cada una tiene una solución distinta — subir el techo del plan, separar los pools gratuito y de pago, o contactar directamente al cliente problemático.

Cuándo necesitas más que esto

Si empiezas a ver credential stuffing coordinado, probablemente ya pasaste del rate limiting artesanal y entraste a herramientas dedicadas contra abuso. La guía de OWASP sobre consumo irrestricto de recursos es el punto de partida correcto para entender cómo luce una infraestructura profesional contra abuso, pero para una API pública pequeña el enfoque por capas descrito arriba — por IP en el borde, por clave en el gateway, un token bucket y topes por endpoint en las rutas caras — cubre los casos comunes sin convertirse en un proyecto en sí mismo.

El objetivo no ser inquebrantable. El objetivo es que el abuso sea caro para el atacante y barato para ti.

Preguntas frecuentes

¿Necesito rate limiting si mi API es pequeña y privada?

Si es verdaderamente privada — usada solo por tu propio front end y un par de integraciones internas — probablemente puedas saltarlo. En el momento en que una API key está en el repo de un integrador externo, en una app móvil o en un SDK público, es efectivamente pública.

¿Token bucket o ventana fija para una primera versión?

Cualquiera funciona. Token bucket da una respuesta más suave ante tráfico en ráfagas. Ventana fija es lo que la mayoría de gateways gestionados trae por defecto y es más simple de razonar. Elige el que tu gateway soporte de forma nativa.

¿Debería publicar mis límites exactos?

Sí, al menos la forma. Publicar los números invita a que los clientes optimicen, que suele ser lo que quieres. Ocultarlos no detiene el abuso; solo frustra a los clientes bien portados.

¿Qué hay de DDoS?

El rate limiting en el borde es una capa, no la respuesta completa. Para ataques volumétricos sostenidos eventualmente querrás un servicio dedicado de mitigación de DDoS frente al gateway.

Fuentes