Guías de seguridad
Cómo elegir las cabeceras de seguridad: cuáles siguen haciendo falta, cuáles están obsoletas y cuáles hacen daño
Muchas listas de cabeceras de seguridad están desactualizadas. Qué cabeceras poner hoy y cuáles quitar: MDN advierte que X-XSS-Protection puede crear XSS.
Hay ejemplos de configuración de cabeceras por todas partes. El problema es que la mayoría dejaron de actualizarse. Si copias una lista que era correcta hace unos años, te traes cabeceras que ya no cumplen ninguna función, y una que puede hacer daño activamente.
① Las seis que vale la pena poner hoy
Nuestro analizador de cabeceras de seguridad evalúa estas seis. Las cabeceras obsoletas se excluyen a propósito.
- Content-Security-Policy
- Declara de dónde pueden venir los scripts y los recursos. Es el control central que reduce lo que puede hacer un XSS. Su directiva
frame-ancestorstambién regula la inserción en marcos - Strict-Transport-Security
- Indica al navegador que vuelva siempre por HTTPS, cerrando la primera petición en texto plano (
max-agemásincludeSubDomains) - X-Frame-Options
- Rechaza que otros sitios te inserten en un marco: defensa contra el clickjacking. En la práctica se pone junto con
frame-ancestorsde CSP - X-Content-Type-Options
nosniff. Impide que el navegador deduzca un tipo a partir del contenido, lo que reduce los incidentes en que un archivo subido se interpreta como algo que no debería- Referrer-Policy
- Limita el referente que se pasa a otros sitios, reduciendo la fuga de lo que haya acabado en una URL (partiendo de que nunca pones secretos ahí)
- Permissions-Policy
- Desactiva por defecto capacidades del navegador: cámara, micrófono, geolocalización. Cierra lo que no usas
El orden importa: empieza por lo que no puede romper nada
X-Content-Type-Options, X-Frame-Options, Referrer-Policy y Permissions-Policy son fiables y difícilmente rompen la visualización, así que pueden ir primero. Strict-Transport-Security debe esperar a que HTTPS funcione en todas las rutas: los navegadores la recuerdan, lo que complica dar marcha atrás.
CSP va al final, y poco a poco. Es la que más funciones afecta, y endurecerla de golpe romperá funciones legítimas. Constrúyela con el generador de CSP.
② Lo que ya no cumple ninguna función
Expect-CT: prácticamente obsoleta desde junio de 2021
MDN marca esta cabecera como Deprecated (obsoleta) y explica que solo la implementaron Google Chrome y otros navegadores basados en Chromium, y que Chromium la declaró obsoleta a partir de la versión 107 porque ahora aplica CT por defecto. Una nota en la misma página añade que Expect-CT está prácticamente obsoleta desde junio de 2021.
Dicho de otro modo, el navegador empezó a hacerlo por defecto, así que el sitio ya no tiene nada que indicar. No hay motivo para añadirla a nada nuevo.
③ Lo que ahora puede hacer daño
X-XSS-Protection: obsoleta, no estándar y capaz de crear XSS
MDN muestra en esta cabecera tanto el aviso Deprecated como el de Non-standard, además de una advertencia: «Aunque esta función puede proteger a usuarios de navegadores antiguos que no admiten CSP, en algunos casos X-XSS-Protection puede crear vulnerabilidades XSS en sitios que por lo demás son seguros».
Su recomendación no deja lugar a dudas: «Se recomienda usar Content-Security-Policy en lugar del filtrado XSS».
Es el caso decisivo contra «cuantas más cabeceras, mejor». Un ajuste añadido de buena fe puede, en las circunstancias adecuadas, convertirse en la superficie de ataque. Si no la envías, no la añadas; si ya la envías, planifica quitarla. Sobre el fallo de fondo, consulta qué es XSS.
Cómo es una lista desactualizada
CSP, HSTS, X-Frame-Options y nosniff, y además
X-XSS-Protection: 1; mode=block
Expect-CT: max-age=…
Public-Key-Pins: …
Es una lista más larga, y algunos analizadores incluso le pueden dar más puntuación. Pero frente a los navegadores actuales, esas entradas extra o no hacen nada o pueden hacer daño.
Cómo es la práctica actual
CSP en el centro y las otras cinco como apoyo.
Las cabeceras obsoletas no se añaden, y se quitan donde estén. El esfuerzo dedicado a la calidad de la CSP (en concreto, cuánto 'unsafe-inline' has eliminado) aporta mucha más defensa real que alargar la lista.
La premisa: las cabeceras no corrigen la vulnerabilidad en sí
Defectos de la aplicación (XSS, falta de autorización, subidas)
ninguna cantidad de cabeceras los elimina
↓ cuando se produce uno
Lo que regulan las cabeceras
adónde se pueden enviar datos · si la página se puede insertar en un marco · si se permite texto plano = limitar la propagación
Añadir CSP a un sitio con un fallo XSS no elimina el XSS; reduce lo que se puede hacer con él. Así que el orden es: corrige el defecto de la aplicación y luego añade las cabeceras como una línea más. Y también al revés: una puntuación perfecta de cabeceras no prueba que el sitio sea seguro.
Comprobar tu propio sitio
Mide lo que se devuelve de verdad
Lee las respuestas, no los archivos de configuración. Los proxies inversos, las CDN, los frameworks y la propia aplicación añaden o sobrescriben cabeceras, así que lo configurado y lo enviado no siempre coinciden. Nuestro analizador de cabeceras mide directamente una URL.
Busca cabeceras obsoletas en la respuesta
Si aparecen X-XSS-Protection o Expect-CT, planifica quitarlas. Sobre todo la primera: como se ha visto, está documentado que puede crear una vulnerabilidad.
Añade las cuatro que no pueden romper nada
X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin y una Permissions-Policy que cierre las capacidades que no usas. Fiables, y difícilmente afectan a la visualización.
Deja HSTS para cuando HTTPS funcione del todo
Strict-Transport-Security la recuerda el navegador, así que activarla mientras HTTPS aún falla complica la recuperación. Confirma primero que todas las rutas sirven HTTPS. Los fundamentos de los certificados están en qué es Let's Encrypt.
Introduce CSP poco a poco y endurécela
Empieza permisiva y ve endureciéndola, con el objetivo de eliminar 'unsafe-inline': hasta dónde llegues en eso decide en gran parte cuánta protección da la CSP. Constrúyela con el generador de CSP y, de paso, repasa el resto de la lista de comprobación de seguridad básica.
La opinión de este sitio: en la configuración copiada, la antigüedad de la fuente decide su seguridad
Las cabeceras de seguridad son el ejemplo típico de ajuste que se copia y pega, y precisamente por eso la antigüedad de la fuente determina lo seguro que es el resultado. Las dos cabeceras de este artículo fueron correctas en su día. X-XSS-Protection fue más allá: la recomendación de entonces es la advertencia de hoy.
Nuestra postura es tratar la configuración de cabeceras como un ajuste que se revisa de vez en cuando, no una tarea que se completa una vez, y no perseguir la puntuación de un analizador, ya que una puntuación puede subir al añadir una cabecera obsoleta. Dedica el tiempo a la calidad de tu CSP en lugar de a la longitud de la lista.
Fuentes (primarias)
- MDN Web Docs, «X-XSS-Protection» — developer.mozilla.org (los avisos Deprecated y Non-standard, la advertencia de que puede crear vulnerabilidades XSS en sitios por lo demás seguros y la recomendación de usar CSP en su lugar)
- MDN Web Docs, «Expect-CT» — developer.mozilla.org (el aviso Deprecated, la retirada en Chromium 107 y su motivo, y la nota de que está prácticamente obsoleta desde junio de 2021)
Ambas consultadas el 5 de septiembre de 2026.
Para seguir leyendo
- Herramientas: analizador de cabeceras de seguridad / generador de CSP
- Glosario: qué es XSS / qué es el clickjacking / qué es CORS
- Fundamentos: la lista de comprobación de seguridad básica
FAQ
Q¿Debo poner X-XSS-Protection?
No. MDN marca esta cabecera como Deprecated (obsoleta) y Non-standard (no estándar), y advierte de que, aunque puede proteger a usuarios de navegadores antiguos que no admiten CSP, en algunos casos X-XSS-Protection puede crear vulnerabilidades XSS en sitios que por lo demás son seguros. Su recomendación es explícita: usar Content-Security-Policy en lugar del filtrado XSS. Si no la envías, no la añadas; si la envías, planifica quitarla.
Q¿Sigue haciendo falta Expect-CT?
No. MDN la marca como Deprecated y explica que solo la implementaron Google Chrome y otros navegadores basados en Chromium, y que Chromium la declaró obsoleta a partir de la versión 107 porque ahora aplica Certificate Transparency por defecto. Una nota en la misma página indica que la cabecera está prácticamente obsoleta desde junio de 2021. No hay motivo para añadirla a nada nuevo.
QEntonces, ¿cuáles debo poner?
Las seis que evalúa nuestra herramienta de análisis de cabeceras son un buen punto de partida: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy y Permissions-Policy. Las cabeceras obsoletas se dejan fuera a propósito. En cuanto al orden, añade primero las fiables y que difícilmente rompen algo (nosniff, X-Frame-Options), e introduce CSP poco a poco porque es la que más funciones afecta.
QSi pongo todas las cabeceras, ¿el sitio es seguro?
No. Las cabeceras no corrigen las vulnerabilidades de tu aplicación; limitan hasta dónde se extiende el daño. Añadir CSP a un sitio con un fallo XSS no elimina el XSS: reduce lo que se puede hacer con él. Corrige primero el defecto de la aplicación y añade las cabeceras como una línea de defensa más. Y al revés: una puntuación perfecta en un analizador de cabeceras no prueba que un sitio sea seguro.