Express.js
Reverse proxies y trust proxy
Explica cómo reverse proxies modifican IP, protocolo y host, y cómo configurar trust proxy sin aceptar forwarded headers controlados por clientes.
- Última actualización
- Actualizada
- Nivel
- Profundización
Express.js
Explica cómo reverse proxies modifican IP, protocolo y host, y cómo configurar trust proxy sin aceptar forwarded headers controlados por clientes.
Cuando Express está detrás de un proxy, la conexión que observa no es necesariamente la del cliente. trust proxy define qué información reenviada puede considerarse confiable.
En producción suele existir infraestructura delante de Node:
cliente
↓ HTTPS
CDN / load balancer / reverse proxy
↓ HTTP o HTTPS interno
ExpressEl proxy puede terminar TLS, asignar IP, comprimir, cachear, limitar tráfico y añadir headers Forwarded o X-Forwarded-*.
Sin configuración, Express puede creer que:
secure no debe enviarse.Pero confiar en headers reenviados sin controlar la topología permite spoofing.
app.set('trust proxy', 1);Esto confía en un hop. También puede utilizarse una lista de subnets o una función.
No copies true por defecto. Significa confiar en el header más a la izquierda según el algoritmo y puede permitir que el cliente controle req.ip, req.protocol o host derivado si existe un camino directo.
Se calculan usando la cadena de proxies y la configuración. Son útiles para logging/rate limiting, pero una IP rara vez identifica una persona de forma estable.
Puede reflejar X-Forwarded-Proto. Afecta redirects y cookies.
Puede considerar X-Forwarded-Host. No construyas URLs o redirects confiando en cualquier host recibido.
Session middleware puede necesitar saber que el cliente original usó HTTPS, aunque la conexión interna sea HTTP.
X-Forwarded-For: client, proxyA, proxyBLa interpretación debe caminar desde el peer conocido hacia afuera hasta encontrar un hop no confiable. Confiar simplemente en el primer valor permite falsificación.
Configurar “1 hop” falla si existen caminos con diferente número de proxies. Un atacante podría alcanzar Express por una ruta más corta.
Prefiere ranges de red conocidos o una política de infraestructura estable.
El cliente controla Host salvo que proxy lo normalice. Riesgos:
Usa una base URL configurada o whitelist de hosts:
const publicBaseUrl = new URL(config.publicBaseUrl);No construyas enlaces sensibles desde req.get('host') sin validación.
Si el proxy termina TLS:
Secure cookies deben basarse en protocolo original confiable.Evita loops cuando la app no reconoce X-Forwarded-Proto.
Antes de usar req.ip:
La limitación en edge suele resistir mejor ataques volumétricos.
Forwarded es estándar; X-Forwarded-For, Proto y Host son ampliamente usados. La plataforma define cuáles envía y cómo sobrescribe valores del cliente.
Express y middlewares pueden preferir headers específicos; documenta la integración real.
Coordina:
client timeout
> proxy upstream timeout
> app deadline
> dependency timeoutsSi el proxy corta primero, Express puede continuar trabajo inútil. También coordina límites de body, keep-alive y header timeout.
Algunos load balancers transmiten metadata a nivel TCP mediante PROXY protocol. Node no lo interpreta automáticamente en un servidor HTTP normal; requiere soporte específico en infraestructura o librería.
Aplicación en Kubernetes detrás de ingress:
req.protocol es https.Secure.PUBLIC_BASE_URL configurada.Si el puerto de la app es público además del proxy, un atacante puede enviar forwarded headers directamente. Cierra el acceso de red o configura trust solo para peers conocidos.
Registra por separado:
No registres headers completos sin redacción.
trust proxy: true sin analizar.trust proxy afecta IP, protocolo y host.trust proxy: true puede ser peligroso?Testing unitario del backend comienza la estrategia de verificación desde reglas y casos de uso aislados.