Las cabeceras de seguridad, explicadas
Una cabecera de seguridad es una sola línea en una respuesta HTTP que cambia lo que el navegador del visitante puede hacer con tu página: ejecutar scripts solo desde fuentes nombradas, no volver a hablar HTTP sin cifrar, negarse a ser encuadrada, negarse a adivinar tipos de contenido. Ninguna necesita código, una biblioteca ni un reinicio — y sin embargo la mayoría de los sitios web envía pocas o ninguna, y por eso la mayoría saca F cuando un escáner lo comprueba. Este artículo recorre cabecera por cabecera qué detiene realmente cada una, explica la epidemia de efes y da el orden de corrección que recupera más protección por hora de trabajo. Para ver el veredicto de tu propio sitio, ejecuta primero la comprobación de cabeceras de seguridad y lee con tus resultados abiertos.
Las cabeceras son instrucciones para el navegador, no armadura del servidor
Empieza por lo que una cabecera no es. Una cabecera de seguridad no parchea tu aplicación, no filtra tu tráfico ni autentica a nadie. Es una declaración que el servidor adjunta a una respuesta, y el navegador —el navegador del visitante, en la máquina del visitante— la hace cumplir desde ese momento. Suena débil hasta que notas cuántos ataques ejecuta el navegador en nombre del atacante: correr un script que alguien inyectó en un campo de comentarios, cargar tu página de acceso dentro de un marco invisible en un sitio hostil, tratar un archivo de texto subido como HTML porque su contenido parecía de script. Las cabeceras son la forma en que el servidor dice al navegador, por adelantado, cuáles de esos movimientos nunca son legítimos en este sitio.
También son defensa en profundidad, y deben leerse así. Las referencias canónicas de este espacio son la documentación HTTP de MDN, que especifica la sintaxis y la semántica de cada cabecera, y el Proyecto de Cabeceras Seguras de OWASP, cuyos valores recomendados señala la guía de pruebas de la Guía de Pruebas de Seguridad Web de OWASP. Ninguna de las dos fuentes promete que las cabeceras hagan seguro un sitio. Prometen algo más estrecho y verdadero: con las cabeceras puestas, clases enteras de ataques ejecutados por el navegador dejan de funcionar incluso cuando un fallo de la aplicación da al atacante un punto de apoyo.
Qué detiene realmente cada cabecera
Content-Security-Policy impide que los scripts inyectados se ejecuten. El XSS y sus primos —un comentario almacenado con un script, un script de skimming inyectado mediante una etiqueta de terceros comprometida— necesitan que el navegador ejecute código que el sitio nunca quiso. Una CSP es una lista de permitidos: script-src nombra los orígenes de los que pueden venir los scripts, y todo lo demás, incluidos los scripts en línea y cualquier cosa cargada desde el servidor de un atacante, se rechaza. Sus formas débiles son famosas: una política que contiene 'unsafe-inline' deja correr todos los scripts en línea, incluido el inyectado, y por eso el comprobador trata esa política como débil y no como buena. CSP es la cabecera más pesada de desplegar y la que más detiene.
Strict-Transport-Security detiene la degradación. La primera vez que un visitante escribe tu dominio sin esquema, o sigue un enlace http:// antiguo, esa petición cruza la red en claro, donde puede ser despojada, redirigida o leída —cookie de sesión incluida—. HSTS dice al navegador: durante los próximos max-age segundos, reescribe cada URL http:// de este host a https:// antes de que nada salga de la máquina, y rechaza los clics que ignoran errores de certificado. Un límite honesto: HSTS solo protege a los visitantes cuyos navegadores ya han visto la cabecera una vez (las listas de precarga integradas en los navegadores existen para cerrar exactamente esa brecha de la primera visita), y solo se honra cuando llega ella misma sobre HTTPS.
La protección contra marcos detiene el clickjacking. Si tus páginas pueden incrustarse en un marco, un sitio hostil puede tender tu interfaz real bajo una capa transparente de botones propios y cosechar los clics: la víctima ve una página inofensiva y aprueba una transferencia. La directiva de CSP frame-ancestors (y su hermana mayor, X-Frame-Options: DENY o SAMEORIGIN) nombra quién puede encuadrarte; todos los demás reciben un marco vacío. X-Content-Type-Options: nosniff detiene un truco más silencioso: los navegadores históricamente adivinaban el Content-Type declarado y ejecutaban archivos como scripts o HTML cuando el contenido lo parecía, convirtiendo una subida inocente en XSS almacenado. nosniff acaba con las adivinanzas: el tipo declarado es el tipo.
Referrer-Policy detiene la fuga de URL. Cuando un visitante hace clic desde tu página a otro sitio, el navegador enviaba históricamente la URL completa de tu página como Referer —incluidos los tokens de restablecimiento de contraseña, términos de búsqueda o identificadores que llevara dentro—. Una política de strict-origin-when-cross-origin o más estricta envía solo el origen entre sitios y nada a destinos http propensos a la degradación. Permissions-Policy detiene el abuso de funciones: declara qué capacidades potentes del navegador —cámara, micrófono, geolocalización, gestores de pago— puede usar este sitio en absoluto, para que un marco o script inyectado no pueda pedirlas en silencio en tu nombre. Y la cabecera extra, Cross-Origin-Opener-Policy, corta el vínculo window.opener entre tu página y las ventanas emergentes de otros orígenes, aislando tu contexto de navegación de las páginas que podrían sondearlo.
Por qué tantos sitios sacan F
Porque la configuración por defecto de nadie envía estas cabeceras. Un servidor web de serie, un andamiaje de framework de serie, un alojamiento estático de serie: cada uno envía respuestas con como máximo una o dos de las seis, y las dos más valiosas —CSP y Permissions-Policy— requieren decisiones sobre el sitio concreto, así que ninguna configuración por defecto puede enviarlas con seguridad. La responsabilidad se parte entonces en tres: el equipo del framework supone que el servidor añade cabeceras, el equipo del servidor supone que lo hace el framework, y el CDN de delante reescribe lo que le place de todos modos. Las cabeceras caen por la grieta, en silencio, porque sin ellas nada se rompe visiblemente. Un sitio con F suele verse y funcionar exactamente como uno con A; la diferencia solo aparece el día en que un ataque necesita la cooperación del navegador.
Las cifras publicadas coinciden con esa historia. La muestra publicada de un escáner, recogida en el resumen semanal de herramientas del 2026-11-04, encontró que el 65% de los sitios escaneados sacaba F y el 51% no enviaba ninguna Content-Security-Policy. Trátalas como lo que son —la muestra de un escáner, publicada por un tercero, no una medición de toda la web ni un dato nuestro—, pero la dirección la corrobora la experiencia de cualquier operador: las cabeceras son ese raro control de seguridad cuya ausencia es la norma estadística. Y esa es también la buena noticia escondida en la estadística: el listón está en el suelo, y subirlo es configuración, no ingeniería.
Orden de corrección, por impacto por hora
Trabaja en el orden que la comprobación de cabeceras de seguridad hace evidente. Primero, las de una línea: X-Content-Type-Options: nosniff, la protección contra marcos y una Referrer-Policy sensata —treinta y cinco de los cien puntos, unos minutos de trabajo y un riesgo de rotura prácticamente nulo en un sitio normal—. Segundo, HSTS —veinte puntos más—, pero solo después de verificar que cada página, subdominio y redirección heredada funciona de verdad sobre HTTPS, porque un max-age largo no se puede desenviar. Tercero, Permissions-Policy: lista las funciones que tu sitio usa de verdad y desactiva el resto; diez puntos por una línea cuidadosa.
Al final, y despacio, CSP. Sus 35 puntos son el bloque individual mayor y la única corrección que puede tumbar tu propio sitio. Despliégala primero como Content-Security-Policy-Report-Only con un endpoint de informes, lee una semana de violaciones, reescribe los scripts en línea y los manejadores de eventos que señale —o adopta nonces, como recomienda la guía de MDN— y cambia a aplicación forzosa solo cuando los informes se callen. Añade Cross-Origin-Opener-Policy: same-origin siempre que no dependas de flujos de ventanas emergentes entre orígenes; en nuestra tabla no puntúa, pero es un aislamiento barato. Después vuelve a ejecutar la comprobación y confirma que las cabeceras que añadiste en el origen sobrevivieron de verdad al CDN y a los proxies que tienen delante.
Lo que las cabeceras no pueden hacer
No pueden arreglar el agujero, solo reducir lo que un atacante puede hacer a través de él. Una CSP no repara el campo de comentarios que no escapó su entrada; hace que la carga inyectada se niegue a ejecutarse. HSTS no repara una cadena de certificados rota —ese es el territorio del calificador SSL— y ninguna cabecera sustituye a los parches, las copias de seguridad o el control de acceso. Lee una nota perfecta en cabeceras como una puerta bien cerrada en un edificio cuyos otros pisos aún necesitan sus propias comprobaciones, que es para lo que sirve la comprobación de salud del sitio.
Tampoco pueden ponerse y olvidarse. Una CSP escrita para el sitio del año pasado bloquea en silencio el widget de pago de este año —o peor, se afloja con un * a toda prisa y deja de significar algo—. Trata el conjunto de cabeceras como el resto de tu configuración: versionado, revisado cuando el sitio cambia y vuelto a comprobar tras cada cambio de plataforma. La comprobación lleva diez segundos; ejecútala cada vez que cambie la pila que está delante de tus páginas, y la epidemia de efes seguirá siendo la estadística de otro.