Qué hace en realidad
Todo visitante hace peticiones. Un rate limit dice: de un mismo cliente aceptaré estas tantas en estos tantos segundos, y todo lo que pase de ahí se rechaza. Esa es toda la idea — es un contador con una consecuencia.
Lo que lo hace valioso es la asimetría. Un scraper, un script de credential stuffing o una integración descontrolada son idénticos a un navegador a nivel de una sola petición; no puedes distinguirlos inspeccionando una. Pero se comportan de forma completamente distinta a lo largo del tiempo: una persona lee una página y hace unos pocos clics por minuto, mientras que un script hace cientos. El rate limiting detecta el comportamiento en lugar del contenido, y por eso detiene ataques que ninguna firma reconocería.
Elegir un número que no haga daño
El error es elegir un límite por intuición. Parte de lo que tu tráfico real ya hace: mira a tu visitante legítimo más activo durante una hora normal y luego pon el límite cómodamente por encima. Un límite que solo un bot puede alcanzar hace su trabajo de forma invisible; un límite que un cliente entusiasta puede disparar es un ticket de soporte que te has creado tú mismo.
Dos detalles te salvan de la mayoría de los falsos positivos. Primero, recuerda que varias personas pueden compartir una misma dirección — una oficina, un colegio, el NAT de un operador móvil — así que un límite calibrado para "un humano" castigará a todo un edificio. Segundo, recuerda tu propio tráfico: la monitorización, los health checks, la integración de un socio y tu CI vienen todos de unas pocas direcciones con mucha frecuencia, y son los primeros clientes legítimos que un límite nuevo suele romper.
Empieza deliberadamente holgado. Un límite que ajustas tras una semana de observación sale mucho más barato que uno que tienes que relajar después de que un cliente se queje.
No todas las rutas merecen el mismo límite
Un único número para todo el sitio es un compromiso con el que nadie queda contento — lo bastante holgado para navegar significa inútil en un formulario de login, y lo bastante estricto para el login significa una página de producto rota.
Piensa en términos de lo que te cuesta una petición y de lo que gana el atacante al abusar de ella. Los endpoints de login, restablecimiento de contraseña y checkout son baratos de pedir y valiosos de atacar, así que se llevan los límites más estrictos — una persona inicia sesión una vez, no cuarenta veces por minuto. Los endpoints de búsqueda y de API son caros de servir y atractivos de scrapear: limítalos según lo que necesita una integración real. Las páginas normales y los recursos estáticos son baratos y muy usados por personas reales, así que necesitan límites generosos o ninguno, porque la caché de la CDN ya los está absorbiendo.
En cdn.com.tr el límite de peticiones se puede definir para toda la cuenta y también por regla de entrega, que es lo que hace esto práctico: una regla estricta que coincida con tu ruta de login y otra más holgada para el resto del sitio.
Por qué el edge es el sitio adecuado
El rate limiting dentro de tu aplicación funciona, en el sentido de que el código se ejecuta. Pero para cuando tu aplicación puede contar una petición, ya ha aceptado la conexión, ha ocupado un worker y probablemente ha tocado la base de datos — el ataque ya te ha costado justo el recurso que intentabas proteger. Bajo una avalancha, el propio limitador se convierte en parte de lo que se cae.
Aplicado en el edge, el rechazo ocurre cerca del cliente, antes de que el tráfico llegue siquiera a tu origen. Tu servidor nunca lo ve, así que el coste no es tuyo. Por eso también el rate limiting en el edge sigue funcionando cuando tu origen ya está sufriendo: el límite no compite por los recursos que está defendiendo.
Rate limiting vs WAF vs protección DDoS
Estos tres términos se usan indistintamente y hacen trabajos realmente diferentes.
El rate limiting cuenta. Sabe con qué frecuencia pide algo un cliente, y nada sobre qué está pidiendo. Detiene la fuerza bruta, el scraping y el machaque accidental.
Un WAF inspecciona. Lee la petición y bloquea las que parecen inyección SQL, cross-site scripting o un exploit conocido — una sola petición maliciosa se detecta al primer intento, por muy despacio que llegue.
La protección DDoS absorbe. Cuando el tráfico es tan grande que solo contarlo ya te desbordaría, el volumen tiene que ser absorbido por capacidad de red repartida en muchas ubicaciones.
Necesitas los tres porque cada uno cubre el punto ciego de los otros: una petición ingeniosa que un contador dejaría pasar, mil peticiones de aspecto inocente en las que un WAF no ve nada raro, y un millón de peticiones que ninguna máquina puede siquiera evaluar. En cdn.com.tr forman parte del mismo edge y se configuran desde un solo panel.
Ponerlo en marcha sin romper nada
Pon el límite lo bastante alto como para esperar que nunca se dispare, y luego observa. Mira qué se rechazó de verdad: si es un scraper o un script de login, aprieta con confianza; si es tu propia monitorización o la integración de un cliente, acabas de aprender algo antes de que te costara una queja.
Mantén las excepciones honestas y escasas — tu monitorización y las integraciones de socios conocidos, no "quien se quejó más fuerte". Y trata el límite como un número vivo: el tráfico crece, se lanza una app móvil, una integración duplica su frecuencia de sondeo. Un límite que era generoso el año pasado puede convertirse silenciosamente en la razón por la que una función parece rota.
Preguntas frecuentes
¿Cuál es un buen rate limit para empezar?
No hay un número universal — depende de lo que hagan tus usuarios reales. Mide tu visitante legítimo más activo en una hora normal, pon el límite cómodamente por encima y ajústalo solo después de observar qué se rechaza. Los límites estrictos van en las rutas de login y de restablecimiento de contraseña, no en las páginas normales.
¿El rate limiting puede bloquear a clientes reales?
Puede, si se configura demasiado estricto — sobre todo donde muchas personas comparten una misma dirección (oficinas, colegios, redes móviles) o donde tu propia monitorización e integraciones consultan con frecuencia. Empezar holgado e ir ajustando según el tráfico observado evita casi todo eso.
¿Basta el rate limiting para detener un ataque DDoS?
No. El rate limiting maneja el abuso de un número manejable de clientes. Un ataque distribuido envía tráfico desde demasiadas fuentes como para que contar sirva de algo — eso requiere capacidad de absorción DDoS delante de tu origen, con el rate limiting haciendo el trabajo más fino por detrás.
¿Debería aplicar el rate limiting en mi aplicación?
Los límites a nivel de aplicación son útiles para reglas de negocio por cuenta ("este plan tiene 1000 llamadas a la API al día"). Para protección contra abusos el edge es mejor: la petición se rechaza antes de llegar a tu servidor, así que no te cuesta nada y sigue funcionando mientras tu origen está bajo presión.