X-XSS-Protection es un encabezado HTTP que habilita el filtrado XSS integrado en algunos navegadores. Aunque los navegadores modernos se basan más en la Política de Seguridad de Contenidos, este encabezado proporciona una capa adicional de protección para los navegadores más antiguos. Se puede configurar para bloquear o sanear los intentos de XSS detectados.
X-XSS-Protection es una cabecera de respuesta heredada que controlaba el auditor de XSS integrado que en su día incorporaron Internet Explorer, Edge y los navegadores basados en Chromium. Los valores iban desde 0 (desactivar el filtro), pasando por 1 (activar y sanear el contenido señalado), hasta 1; mode=block (activar y bloquear toda la página al detectar algo). El filtro intentaba detectar scripts reflejados, código que aparece tanto en la petición como en la respuesta, y neutralizarlo antes de que se ejecutara. Los navegadores modernos han eliminado por completo este filtro: Chrome, Edge y Safari ya no actúan sobre la cabecera, y nunca existió en Firefox. Ahora se considera obsoleta, sustituida por Content Security Policy.
La cabecera importaba históricamente porque ofrecía cierta mitigación del XSS reflejado en navegadores anteriores a una Content Security Policy madura. En la práctica los filtros resultaron poco fiables y, peor aún, introdujeron sus propias vulnerabilidades: el modo de saneamiento podía abusarse para desactivar de forma selectiva scripts legítimos, y los investigadores encontraron canales laterales de fuga de información y de XSS universal creados por el propio auditor. Por eso los fabricantes la marcaron como obsoleta y la eliminaron. Hoy, enviar 1; mode=block es en el mejor de los casos inerte y en el peor reactiva un comportamiento con errores en un navegador antiguo. Las recomendaciones actuales aconsejan o bien omitir la cabecera o bien enviar explícitamente 0, y apoyarse en una CSP sólida y en la codificación de salida en su lugar.
No dependas de X-XSS-Protection. Configúrala a 0 o déjala desactivada, y dedica tu esfuerzo a los controles que realmente detienen el XSS hoy en día: codificación de salida consciente del contexto, validación de entrada, saneamiento del DOM para cualquier HTML que insertes, cookies HttpOnly para que los tokens robados sean más difíciles de alcanzar, y una Content Security Policy estricta basada en nonce. Cuando el riesgo de XSS proviene de JavaScript de terceros o inyectado en lugar de tus propias plantillas, cside añade una capa complementaria, enrutando los scripts de terceros a través de un proxy híbrido, analizando la carga y bloqueando el comportamiento malicioso en tiempo real mientras conserva un registro forense, nada de lo cual proporcionó jamás la cabecera obsoleta.
Ningún navegador actual actúa sobre ella; Chrome, Edge y Safari eliminaron el filtro y Firefox nunca lo tuvo. La mayoría de las recomendaciones aconsejan omitir la cabecera o enviar 0, y luego apoyarse en una Content Security Policy sólida y en la codificación de salida. Enviar 1; mode=block no aporta nada útil y puede desencadenar un comportamiento antiguo y con errores.
Los auditores solo detectaban XSS reflejado simple mientras creaban repetidamente nuevos problemas, incluidas formas de desactivar scripts concretos y errores de cross-site-scripting universal o de fuga de información. Corregirlos de forma fiable resultó impracticable, y Content Security Policy ofrecía una alternativa estandarizada mucho más sólida, así que los fabricantes optaron por eliminar el filtro por completo.
We answer client-side security questions every day. Bring yours.