Limitación de frecuencia: la defensa del buzón ante envíos masivos
Actualizado: 2026-05-06 · 8 min de lectura
Por qué hay que limitar la frecuencia de envío
No solo los buzones de preguntas: cualquier servicio web en el que los usuarios pueden enviar datos libremente corre el riesgo de sufrir ataques de envíos masivos. Si un usuario malintencionado o un bot envía cientos o miles de mensajes en poco tiempo, pueden surgir 2 problemas.
En primer lugar, el panel del dueño del buzón se llena de spam. Las preguntas legítimas quedan enterradas bajo una montaña de spam y ya no se encuentran. El dueño del buzón se ve obligado a borrar el spam uno por uno, y puede que acabe harto de gestionar el buzón de preguntas.
En segundo lugar, el servidor soporta una carga excesiva. Si se concentran cientos de solicitudes en un segundo, se supera la capacidad de procesamiento del servidor, y existe el riesgo de que incluso el acceso de los usuarios legítimos se ralentice o, en el peor de los casos, de que el servicio se detenga. Es una forma de ataque DDoS (Distributed Denial of Service).
La limitación de frecuencia es un mecanismo que contiene estos problemas con un enfoque sencillo: «poner un límite a la frecuencia de envío».
Cómo funciona la limitación de frecuencia: la idea del cubo de fichas
Hay varias formas de implementar la limitación de frecuencia, pero la más fácil de entender de forma intuitiva es el modelo del «cubo de fichas» (Token Bucket).
Imagina que dentro de un cubo (un recipiente) hay fichas (monedas). Cada vez que envías una pregunta, se gasta una ficha. Las fichas se reponen automáticamente a un ritmo constante. Cuando el cubo se vacía, no puedes enviar nada hasta que se repongan las fichas.
Supongamos que se limitan los envíos desde una misma dirección IP a 5 por minuto. En el cubo caben como máximo 5 fichas, y cada minuto se reponen hasta llegar a 5 fichas. Al ritmo al que una persona envía preguntas (de varias decenas de segundos a varios minutos por pregunta), las fichas casi nunca se agotan. Pero si un bot intenta enviar 100 en un segundo, las fichas se agotan con los primeros 5 envíos y se rechazan los 95 restantes.
Lo bueno de este mecanismo es que apenas afecta a los usuarios legítimos y facilita bloquear los envíos masivos malintencionados.
El límite por dirección IP y sus limitaciones
La limitación de frecuencia necesita identificar «de quién es el envío». En servicios como el buzón de preguntas, en los que se puede enviar sin registrarse, una opción es usar la dirección IP del remitente como identificador. Cuando los envíos desde una misma dirección IP superan el límite, se rechazan los que sobran.
El límite por dirección IP también tiene sus limitaciones. En primer lugar, varios usuarios que comparten la misma red (el Wi-Fi de una empresa o de un colegio) envían desde la misma dirección IP. En ese caso, si una persona llega al límite, puede que otros usuarios de la misma red tampoco puedan enviar durante un rato. Eso sí, el límite se fija pensando en un uso normal, así que probablemente los casos en que suponga un problema sean pocos.
En segundo lugar, si un atacante cambia de dirección IP con frecuencia usando una VPN o un proxy, puede esquivar la limitación de frecuencia. Cada vez que cambia de dirección IP se le asigna un cubo nuevo, así que el límite se reinicia.
Una forma de compensar esta limitación es no usar la limitación de frecuencia sola, sino combinarla con la prueba de trabajo (Proof of Work) o con un campo trampa (honeypot). Aunque se cambie de dirección IP para esquivar la limitación de frecuencia, cada envío tiene el coste de cálculo de la prueba de trabajo, y la detección de bots mediante el campo trampa también funciona. Como una de las capas de una defensa en varias capas, la limitación de frecuencia cumple un papel importante.
Si te topas con la limitación de frecuencia
Es raro que un usuario legítimo se tope con la limitación de frecuencia, pero no imposible. Puede ocurrir si envías preguntas seguidas a varios buzones de preguntas en poco tiempo o si pulsas repetidamente el botón Enviar.
Cuando te topas con la limitación de frecuencia, el servidor devuelve el código de estado HTTP 429 (Too Many Requests). En pantalla aparece el mensaje «Demasiadas publicaciones. Espera un momento».
La solución es sencilla. Espera más o menos un minuto y vuelve a enviarla. Con el tiempo el límite se levanta, así que basta con esperar para poder enviar de nuevo. El contenido de la pregunta que escribiste no se borra, así que no hace falta volver a escribirlo.
Lo básico es situar el límite de frecuencia de envío en un nivel al que es difícil llegar al ritmo normal al que una persona envía preguntas. Para enviar una pregunta hay que pensar el contenido, escribirlo y enviarlo, lo que lleva al menos varias decenas de segundos, así que con un uso normal no es habitual tocar el límite.
La filosofía de diseño de la limitación de frecuencia: equilibrio entre comodidad y seguridad
Una de las partes difíciles de diseñar la limitación de frecuencia es fijar el umbral (el valor límite). Si el umbral es demasiado estricto, perjudica la comodidad de los usuarios legítimos; si es demasiado laxo, cuesta más frenar los ataques.
El umbral se piensa tomando como referencia la velocidad a la que actúa una persona. El tiempo que tarda una persona en enviar una pregunta es de varias decenas de segundos, incluso con una pregunta corta y estándar. Si se pone el límite en ese nivel «al que no se llega por poco ni siquiera al ritmo más rápido de una persona», probablemente no se perjudique la comodidad de los usuarios legítimos. En cambio, como un bot intenta hacer entre decenas y cientos de envíos por segundo, un límite de este nivel basta para reducir mucho su velocidad de envío.
La limitación de frecuencia y la prueba de trabajo se complementan. La prueba de trabajo frena los envíos masivos imponiendo un «coste de cálculo por envío», y la limitación de frecuencia limita directamente el «número de envíos por unidad de tiempo». Aunque se resuelva la prueba de trabajo a gran velocidad con una GPU potente, mientras exista la limitación de frecuencia, la frecuencia de envío se queda estancada en el límite. A la inversa, aunque se cambie de dirección IP para esquivar la limitación de frecuencia, cada envío sigue necesitando el cálculo de la prueba de trabajo.
Con esta doble restricción, el atacante tiene que asumir tanto el «coste de cálculo» como el «coste de tiempo», y la relación entre coste y beneficio del spam empeora. Creemos que, más que impedir por completo los ataques, la estrategia de defensa realista es subir su coste hasta que dejen de compensar. La limitación de frecuencia es un componente importante de esa estrategia.