Limitar el abuso: rate limiting / throttling
Aunque una petición sea legítima, mil por segundo desde el mismo cliente
pueden tumbar tu servicio o forzar contraseñas por fuerza bruta. El rate
limiting cuenta las peticiones por clave (IP, usuario, API key) dentro de una
ventana de tiempo y, al superar el máximo, las rechaza con el código de
estado 429 Too Many Requests:
// pseudocódigo de un limitador por ventana
if (contador(clave) >= MAX) {
return res.status(429).json({ error: "Demasiadas peticiones" });
}
El throttling es la variante que ralentiza en lugar de cortar en seco.
Validar SIEMPRE en el servidor
La validación en el cliente (en el navegador) mejora la experiencia, pero no
es seguridad: el cliente está bajo control del atacante, que puede saltarse el
formulario y llamar a tu API directamente con curl.
Nunca confíes en el cliente. Toda entrada que llega al servidor se valida otra vez en el servidor: tipos, rangos, longitudes, formato y reglas de negocio. La validación del cliente es comodidad; la del servidor es la verdadera barrera.
Defensas de alto nivel: captcha y WAF
- Un captcha distingue humanos de bots y frena el registro masivo, el credential stuffing y el spam.
- Un WAF (Web Application Firewall) se sitúa delante de tu aplicación e inspecciona el tráfico para bloquear patrones de ataque conocidos (inyección, scraping, DDoS) antes de que lleguen a tu código.
Son capas adicionales: complementan, no sustituyen, la validación y el escapado dentro de tu aplicación.