Cuando construyes una API en Node.js, una de las decisiones más críticas que afecta la seguridad y la experiencia del usuario es cómo manejas el tráfico entrante. No todos los visitantes son iguales: algunos son clientes legítimos que navegan desde su hogar, otros son empleados corporativos que acceden a través de una VPN, y unos pocos son bots maliciosos que intentan explotar cada vulnerabilidad. El enfoque tradicional de esperar a que un rate limiter dispare una alerta al día siguiente es reactivo y caro. En su lugar, puedes detener el tráfico no deseado en la puerta, antes de que toque un solo controlador de ruta, utilizando la reputación de IP como primera línea de defensa.
En Q2BSTUDIO, como empresa especializada en aplicaciones a medida y soluciones de ciberseguridad, hemos implementado este patrón en múltiples proyectos. La idea es simple: cada solicitud llega con una dirección IP que ya tiene un historial. Puede ser un rango residencial, un datacenter, una VPN conocida o una dirección que ha estado realizando ataques de fuerza bruta durante días. Si sabes qué tipo de IP tienes antes de ejecutar tu lógica de negocio, puedes decidir cómo actuar: bloquear a los atacantes evidentes, desafiar a los sospechosos con un CAPTCHA o dejar pasar sin fricción a los limpios. Esta granularidad es clave para no perder clientes reales por decisiones binarias.
El middleware que te presento no es una pieza genérica; está diseñado para integrarse en flujos existentes de Node.js (18+) usando Express, y se apoya en la API de WhoisFreaks para obtener datos de reputación en tiempo real. Pero lo importante no es la API en sí, sino la arquitectura de decisión que construyes alrededor. Si operas en entornos cloud como AWS o Azure, este enfoque escala sin problemas gracias a cachés distribuidas con Redis. Y si además integras agentes de IA para analizar patrones de comportamiento, puedes refinar aún más las reglas.
Empecemos por el principio: obtener la IP real del cliente. Parece trivial, pero en un despliegue moderno con balanceadores de carga o CDNs, req.socket.remoteAddress te devuelve la IP del proxy, no del visitante. La IP real está en la cabecera X-Forwarded-For. Express no la leerá a menos que configures app.set('trust proxy', true). Hazlo bien o los atacantes podrán suplantar esa cabecera y hacerse pasar por 127.0.0.1. Una vez ajustado, extraemos la IP limpiando el prefijo ::ffff: que Express añade en IPv4 mapeado a IPv6.
El siguiente paso es consultar la reputación. La API devuelve un objeto security con campos como threat_score (de 0 a 100), is_vpn, is_proxy, is_tor, is_known_attacker, is_bot y is_cloud_provider, además de niveles de confianza. Con esta riqueza de datos puedes definir cuatro niveles de acción en lugar de un simple bloqueo binario: permitir, desafiar, exigir autenticación adicional (step-up) o bloquear. Por ejemplo, un threat_score de 40 suele corresponder a un datacenter o VPN comercial, donde muchos usuarios legítimos navegan; un desafío con CAPTCHA es adecuado. Por encima de 75, el tráfico es claramente malicioso y debe recibir un 403.
El middleware que implementamos en Q2BSTUDIO sigue una filosofía de fail-open: si la API de reputación falla (timeout, error 500), la solicitud pasa adelante. Preferimos una pequeña ventana de riesgo que una caída total del servicio. También saltamos las IPs privadas (localhost, health checks) para no gastar créditos ni ralentizar tráfico interno. Y para optimizar, guardamos en caché las respuestas durante 12 horas usando un Map en memoria, aunque en producción con múltiples instancias lo sustituiríamos por Redis.
Una vez que tienes el middleware, puedes combinarlo con otras estrategias de ciberseguridad. Por ejemplo, desde nuestros agentes de IA podemos analizar los patrones de peticiones bloqueadas para ajustar dinámicamente los umbrales del score. También puedes enriquecer los logs con el campo asn y connection_type para crear reglas propias. Además, si usas Power BI o herramientas de BI, puedes visualizar en tiempo real qué IPs están siendo bloqueadas, cuántas pasan por el nivel challenge y cómo evoluciona el tráfico malicioso semana a semana.
En las pruebas que realizamos con 20 IPs extraídas de logs reales, encontramos que dos entradas de Tor exit nodes alcanzaron puntuaciones de 85 y 80, marcadas como atacantes conocidos. La mayoría de las IPs de datacenters y VPNs se agruparon en torno al score 50 sin flags individuales, lo que confirma que una decisión binaria habría sido excesiva o insuficiente. El enfoque de cuatro niveles permitió tratar cada caso según su contexto.
Si quieres implementar esta protección en tu propia API, puedes empezar con el repositorio de WhoisFreaks y adaptarlo a tu stack. Pero recuerda que la reputación IP es solo una capa. En Q2BSTUDIO integramos este tipo de middleware con soluciones cloud en AWS y Azure, automatización de procesos y sistemas de BI para ofrecer una defensa completa y escalable. No se trata solo de bloquear bots; se trata de hacerlo sin romper la experiencia de tus usuarios reales.
Para profundizar, te recomiendo explorar cómo la inteligencia artificial puede mejorar la detección de anomalías en tiempo real, o cómo el desarrollo de aplicaciones a medida puede incorporar estas técnicas desde el diseño inicial. La seguridad proactiva no es un lujo, es una necesidad en el entorno digital actual.
