X-XSS-Protection NO Protege tu Web Contra Ataques de Tipo Cross-Site-Scripting [XSS]

En las auditorías de ciberseguridad que realizamos a empresas seguimos viendo multitud de servidores web (NGINX, Apache, etc), que en 2026 siguen utilizando el HTTP Header X-XSS-Protection.

Al parecer muchas personas aún creen que este header con ese nombre tan explícito los mantiene protegidos contra ataques de tipo Cross-Site-Scripting.

Pero la realidad es muy distinta. Aunque X-XSS-Protection puede proteger a los usuarios de navegadores web antiguos que no admiten Content-Security-Policy (CSP), hay casos en los que puede generar vulnerabilidades XSS en sitios web que en condiciones normales son seguros.

LA REALIDAD DE X-XSS-Protection

• No es una función estandarizada: No recomendamos utilizar funciones no estándar en producción, ya que tienen una compatibilidad limitada con los navegadores y pueden cambiar o eliminarse.
  
  
  
• Obsoleta: Aunque algunos navegadores muy antiguos aún la admitan, es posible que ya se haya eliminado de los estándares web pertinentes, que se esté en proceso de eliminarla o que solo se mantenga por motivos de compatibilidad con navegadores antiguos.
  
  Evita utilizarla y reemplazala por CSP si es posible. Consultando la tabla de compatibilidad podemos ver que por ejemplo, Google Chrome eliminó la compatibilidad con X-XSS-Protection en la release 78 y a fecha de publicación de este artículo estamos en la release 144.

• Advertencia: Aunque esta función puede proteger a los usuarios de navegadores web antiguos que no admiten CSP, en algunos casos, X-XSS-Protection puede provocar vulnerabilidades XSS en sitios web que en condiciones normales son seguros.

El encabezado de respuesta HTTP X-XSS-Protection era una característica de Internet Explorer, Chrome y Safari que impedía que las páginas se cargaran cuando detectaban ataques de tipo cross-site scripting reflejados [RXSS].

Se recomienda sustituirlo por una Content-Security-Policy sólida que deshabilite el uso de JavaScript en línea «unsafe-inline» como la siguiente, en vez de el filtro XSS:

Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self'; font-src 'self'; connect-src 'self'; frame-src 'self'; object-src 'self';" always;

En cada caso la configuración del CSP deberá matrizarse adecuadamente ya que las webs hechas en ciertos CMS como WordPress suelen tener mucho scripting y estilos CSS dentro del código fuente en los archivos .html/.php y eso es incompatible con una CSP robusta, provocando que estilos o código javascript no se ejecute y ciertos elementos de la web no se carguen por bloqueo.

Restringir ‘unsafe-inline’ en CSP es ideal para webs en las que tanto el JavaScript como el CSS de la página se cargan desde archivos externos como miweb/assets/css/styles.css o miweb/assets/js/script.js

X-XSS-Protection VS Content-Security-Policy

• X–XSS–Protection configurado en modo bloqueo en NGINX no es capaz de bloquear el alert:

Content-Security-Policy activado muestra el mensaje en consola informando que se ha bloqueado la ejecución del script por violar la directiva "script-src 'self'"