Cómo comprobar las cabeceras de seguridad de una web con DevTools

Qué vas a comprobar exactamente

Saber cómo comprobar las cabeceras de seguridad de una web no exige instalar una extensión ni enviar la URL a una herramienta externa. El navegador permite observar las cabeceras HTTP recibidas en una respuesta y comprobar si aparecen políticas como Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy o Permissions-Policy.

La palabra importante es respuesta. Al abrir una página, el navegador puede solicitar el documento HTML, hojas de estilo, scripts, imágenes, fuentes y datos de una API. Cada recurso tiene su propia petición y puede recibir cabeceras diferentes. Encontrar una política en una imagen no demuestra que también esté presente en el documento principal; verla en la portada tampoco acredita que todas las rutas del sitio la devuelvan.

Las cabeceras HTTP permiten que el cliente y el servidor intercambien información adicional junto con una petición o una respuesta. La referencia de cabeceras HTTP de MDN explica sus diferentes contextos. En esta comprobación interesan principalmente las que aparecen en Response Headers, ya que representan la información recibida del servidor o de un intermediario como una CDN o un proxy.

DevTools permite confirmar qué recibió el navegador para una respuesta concreta. No certifica por sí solo que toda la web sea segura ni identifica automáticamente una vulnerabilidad explotable.

Cómo abrir Network en DevTools

Los nombres y la posición de los controles pueden cambiar entre Chrome, Edge, Firefox y otros navegadores, pero el procedimiento general es equivalente:

1. Abre la URL exacta que quieres revisar.
2. Abre las herramientas de desarrollo con F12, con Ctrl + Mayús + I en Windows o Linux, o mediante la opción Inspeccionar del menú contextual.
3. Selecciona la pestaña Network o Red.
4. Activa Preserve log si necesitas conservar las peticiones durante redirecciones o cambios de página.
5. Recarga la página con el panel abierto para capturar la solicitud inicial.
6. Filtra por Doc o Document para localizar el documento HTML.
7. Selecciona la fila correspondiente a la URL que quieres analizar.
8. Abre Headers o Cabeceras y localiza Response Headers.

Si estás empezando con estas herramientas, consulta la introducción a los navegadores para desarrollo web y sus DevTools. También ayuda entender cómo funcionan una URL y el protocolo HTTP antes de interpretar peticiones y respuestas.

Identifica el documento principal

Una página puede generar decenas de filas en Network. Antes de buscar una cabecera, confirma que estás examinando el recurso correcto:

• Request URL: debe mostrar la dirección realmente solicitada.
• Request Method: la carga normal de un documento suele utilizar GET.
• Status Code: permite distinguir una respuesta final, una redirección y un error.
• Content-Type: una página HTML convencional suele declarar un tipo compatible con text/html; otros documentos o respuestas de API pueden utilizar tipos distintos.
• Response Headers: contiene las cabeceras recibidas en esa respuesta.

No selecciones una fila únicamente porque contenga el dominio. Un favicon, una llamada a una API o una respuesta de redirección pueden compartirlo y ofrecer resultados distintos.

Descarta interferencias de la caché

DevTools suele incluir la opción Disable cache mientras el panel permanece abierto. Activarla y recargar ayuda a comprobar cambios recién desplegados sin depender de una respuesta reutilizada desde la caché local.

Si la aplicación utiliza un service worker, los detalles de la petición pueden indicar que la respuesta procede de él. Esa respuesta sigue siendo relevante porque es la que ha usado el navegador, pero puede no representar una consulta nueva al servidor de origen. Cuando investigues un cambio, repite la prueba sin caché y, si es necesario, desde una ventana privada o un perfil limpio.

Cabeceras de seguridad que conviene revisar

Cabecera	Qué debes observar	Qué no demuestra por sí sola
Strict-Transport-Security	Su presencia en la respuesta HTTPS y las directivas incluidas.	Que TLS esté completamente bien configurado o que no exista contenido mixto.
Content-Security-Policy	Si se aplica una política y qué recursos restringe.	Que la aplicación esté libre de XSS.
X-Content-Type-Options	El valor nosniff.	Que todos los recursos declaren un tipo MIME correcto.
Referrer-Policy	La política declarada y su efecto en peticiones pertinentes.	Que nunca se envíe información de referencia.
Permissions-Policy	Qué funciones se restringen y para qué orígenes.	Que una función esté siendo utilizada o que el usuario haya concedido permisos.

Cómo interpretar Strict-Transport-Security

Strict-Transport-Security, conocida como HSTS, comunica al navegador una política para acceder posteriormente al host mediante HTTPS. La documentación de Strict-Transport-Security de MDN describe sus directivas y su funcionamiento.

En DevTools podrías encontrar una estructura como esta:

strict-transport-security: max-age=31536000; includeSubDomains

Es un ejemplo de formato, no una configuración que deba copiarse sin analizar el dominio. Revisa estos elementos:

• Respuesta HTTPS: comprueba la respuesta HTTPS final y no atribuyas automáticamente la cabecera de un salto de redirección a toda la cadena.
• max-age: expresa en segundos durante cuánto tiempo debe recordar el navegador la política. Un valor igual a cero tiene un efecto diferente de una duración positiva.
• includeSubDomains: extiende el alcance declarado a los subdominios. Antes de emplearla, todos los subdominios afectados deben estar preparados para funcionar mediante HTTPS.
• preload: su presencia no acredita por sí sola que el dominio figure en una lista de precarga utilizada por los navegadores.

HSTS no sustituye al certificado TLS, no corrige una cadena de certificados defectuosa y no protege la lógica interna de la aplicación. Si no encuentras la cabecera, registra exactamente la URL y la respuesta HTTPS revisadas antes de concluir que está ausente.

Cómo revisar Content-Security-Policy sin auditar toda la CSP

Content-Security-Policy o CSP permite declarar restricciones sobre los recursos que el navegador puede cargar o ejecutar. La referencia de Content-Security-Policy de MDN recoge sus directivas y su sintaxis.

En una comprobación general interesa responder a estas preguntas:

1. ¿El documento HTML recibe una cabecera Content-Security-Policy?
2. ¿Aparece únicamente Content-Security-Policy-Report-Only?
3. ¿Las directivas guardan relación con los scripts, estilos, imágenes y conexiones que utiliza la página?
4. ¿La consola muestra recursos bloqueados o incumplimientos de la política?

Content-Security-Policy-Report-Only permite supervisar una política sin imponer el mismo bloqueo que su versión aplicada. La documentación de CSP Report-Only de MDN ayuda a distinguir ambos modos. Si solo aparece esta cabecera, no registres el resultado como si existiera una política de bloqueo equivalente.

Después de revisar Network, abre Console y recarga la página. Un mensaje relacionado con CSP puede señalar que un recurso incumple una directiva. La ausencia de mensajes durante esa navegación solo indica que no has observado un incumplimiento en las acciones realizadas.

Diseñar y desplegar la política exige inventariar recursos, probar directivas y revisar las funciones de la aplicación. Ese proceso se explica en la guía sobre cómo configurar Content Security Policy en una web. Aquí el objetivo es reconocer la cabecera, distinguir su modo y detectar incoherencias evidentes.

Cómo comprobar X-Content-Type-Options

La comprobación habitual consiste en buscar esta respuesta:

x-content-type-options: nosniff

Según la referencia de X-Content-Type-Options de MDN, nosniff indica al navegador que debe respetar los tipos MIME declarados en los contextos en los que se aplica, en lugar de intentar interpretar determinados recursos como un tipo diferente.

La cabecera no corrige un Content-Type equivocado. Por eso conviene revisar las dos cosas:

1. Selecciona el documento principal y busca X-Content-Type-Options.
2. Filtra después por scripts y hojas de estilo.
3. Abre algunos de esos recursos y consulta el Content-Type de cada respuesta.
4. Anota cualquier tipo inesperado aunque nosniff esté presente.

Una configuración estricta puede hacer visible un problema que antes quedaba oculto por la interpretación flexible del navegador. El diagnóstico debe diferenciar la política recibida del tipo MIME entregado por cada recurso.

Cómo interpretar Referrer-Policy

Referrer-Policy controla cuánta información de referencia puede enviarse en determinadas solicitudes. La documentación de Referrer-Policy de MDN detalla los valores disponibles y cómo influyen el origen y el nivel de seguridad del destino.

En el documento principal podrías encontrar:

referrer-policy: strict-origin-when-cross-origin

Para comprobar su efecto, selecciona una petición secundaria en la que la política pueda intervenir y consulta Request Headers. Si aparece Referer, observa si contiene una URL completa, únicamente el origen o una información diferente. En otras peticiones puede no aparecer.

El resultado depende de factores como la relación entre los orígenes, los protocolos utilizados, el tipo de navegación y la política aplicable. No esperes necesariamente el mismo comportamiento en una petición interna y en otra dirigida a un dominio externo.

Además, una política de referencia puede declararse mediante HTML o aplicarse a elementos concretos. Por tanto, si no aparece la cabecera HTTP, formula el hallazgo con precisión: “la respuesta del documento analizado no incluye la cabecera HTTP Referrer-Policy”. Esa observación no demuestra que no exista ninguna política en otra capa.

Cómo revisar Permissions-Policy

Permissions-Policy permite declarar qué funciones controladas por el navegador pueden utilizar el documento y determinados orígenes. La referencia de Permissions-Policy de MDN explica su sintaxis y las directivas disponibles.

Una respuesta podría contener una estructura como esta:

permissions-policy: camera=(), microphone=(), geolocation=()

El ejemplo expresa restricciones, pero no constituye una plantilla universal. Una aplicación de videoconferencia podría necesitar cámara y micrófono, mientras que una web informativa quizá no utilice esas funciones.

Compara la política con las necesidades reales del proyecto y evita conclusiones automáticas:

• Que la cabecera exista no demuestra que todas las funciones innecesarias estén restringidas.
• Que una función no aparezca en la política no demuestra que la página esté utilizándola.
• El comportamiento también puede depender del navegador, del contexto seguro, de documentos incrustados y de otras políticas.
• La política del documento y el permiso concedido por el usuario son controles diferentes.

Si la intención del proyecto era restringir una capacidad y no aparece la directiva esperada, anótalo como una discrepancia que debe contrastarse con la configuración prevista y con los navegadores compatibles.

Cómo detectar cabeceras ausentes o mal configuradas

No existe una configuración idéntica para todas las webs. Una aplicación con pagos, vídeo, mapas, iframes y servicios externos tiene necesidades diferentes de una página estática. Aun así, puede seguirse un procedimiento ordenado.

1. Busca el nombre exacto en Response Headers

Los nombres de las cabeceras no distinguen entre mayúsculas y minúsculas. Si no encuentras una, confirma que estás examinando Response Headers del documento correcto. Anota la URL final, el código de estado y el recurso seleccionado.

2. Comprueba el valor y el modo de aplicación

La mera presencia de una línea no garantiza que cumpla el objetivo del proyecto. Estas situaciones requieren revisión:

• HSTS presenta un alcance o una duración diferente de la política prevista.
• Solo existe CSP en modo Report-Only cuando se esperaba una política aplicada.
• X-Content-Type-Options no contiene el valor esperado nosniff.
• Referrer-Policy comparte más información de la aceptada por los requisitos de privacidad.
• Permissions-Policy bloquea una función necesaria o no refleja las restricciones previstas.

3. Examina la cadena de redirecciones

Activa Preserve log, introduce la URL HTTP y observa cada respuesta hasta llegar a HTTPS. Registra por separado el estado, la ubicación de destino y las cabeceras de cada salto. Una cabecera presente en la respuesta final no debe atribuirse automáticamente a la redirección inicial.

4. Prueba varias rutas y tipos de respuesta

Repite la revisión en la portada, una página interior y una respuesta de error controlada. Si tienes autorización y resulta relevante, revisa también una zona autenticada. Las diferencias pueden aparecer cuando las rutas pasan por configuraciones distintas, otra aplicación, una CDN o un proxy.

URL probada	Estado	Cabecera	Valor observado	Conclusión limitada
Portada HTTPS	200	HSTS	Valor recibido	Confirmada solo en esta respuesta
Página interior	200	CSP	Política recibida	Comparar con la portada
Ruta inexistente	404	X-Content-Type-Options	Presente o ausente	Revisar consistencia de errores

5. Repite la prueba tras modificar la configuración

Si administras la web, cambia una sola parte cada vez, recarga sin caché y vuelve a registrar el resultado. Una CDN, un balanceador o un proxy inverso puede añadir, eliminar o sustituir cabeceras. La comprobación final debe hacerse sobre la respuesta que recibe el navegador.

Ejemplo práctico de diagnóstico

Supongamos un caso ficticio: se introduce http://www.ejemplo.test con Preserve log activado y Network muestra dos respuestas.

Paso	Respuesta observada	Qué puede concluirse
1	La URL HTTP devuelve una redirección hacia HTTPS.	La petición HTTP observada redirige, pero todavía no se han comprobado las cabeceras del documento final.
2	La URL HTTPS devuelve el documento HTML con estado satisfactorio.	Esta es la respuesta principal en la que deben buscarse HSTS, CSP y las demás políticas.
3	Aparece CSP Report-Only, pero no CSP aplicada.	Se observa una política de supervisión; no puede describirse como una política de bloqueo equivalente.
4	La página interior no devuelve la misma cabecera que la portada.	Existe una diferencia entre las respuestas examinadas que requiere revisar la configuración de ambas rutas.

El informe no debería afirmar que “la web es insegura”. Una conclusión proporcionada sería: “La respuesta HTTPS de la portada incluye una CSP en modo Report-Only, mientras que la página interior analizada no devuelve esa cabecera. Conviene revisar por qué ambas rutas reciben políticas diferentes y confirmar cuál es la configuración prevista”.

DevTools frente a un comprobador externo

Aspecto	DevTools	Comprobador externo
Respuesta observada	La recibida por tu navegador y sesión.	La recibida desde la infraestructura de la herramienta.
Recursos individuales	Permite inspeccionar documento, scripts, CSS, imágenes y API.	Depende de las funciones ofrecidas por el servicio.
Redirecciones	Permite examinar cada salto si se conserva el registro.	Puede mostrar solo el resultado final o un resumen.
Contexto autenticado	Puede observar una sesión autorizada del usuario.	Normalmente se limita a contenido accesible desde el exterior.
Segunda perspectiva	Representa tu entorno concreto.	Puede mostrar diferencias por ubicación, CDN o tratamiento del cliente.

Ambos enfoques pueden complementarse. Si muestran resultados distintos, compara la URL final, el código de estado, la ubicación de la petición, el momento de la prueba y el valor exacto de cada cabecera.

Protección del navegador y seguridad del servidor

Las cabeceras revisadas orientan o restringen determinadas decisiones del navegador. Son una capa de defensa, no un sustituto de la seguridad de la aplicación y del servidor. La introducción de MDN sobre seguridad de sitios web señala que la protección eficaz abarca la aplicación, la configuración del servidor y el código del cliente.

• Las cabeceras pueden controlar: políticas de carga de recursos, tratamiento del transporte, información de referencia, interpretación MIME y acceso declarado a funciones del navegador.
• Otras pruebas deben revisar: autenticación, autorización, sesiones, validación de entradas, consultas a bases de datos, componentes vulnerables, TLS, registros, actualizaciones, copias de seguridad y monitorización.

Una web puede devolver todas las cabeceras analizadas y mantener un fallo grave de autorización. También puede faltar una cabecera sin que esa observación identifique por sí sola una vía de ataque. Un diagnóstico responsable separa el hecho observado, el riesgo que podría existir y las comprobaciones adicionales necesarias.

Checklist para cerrar la revisión

• He abierto Network antes de recargar.
• He identificado el documento HTML principal.
• He anotado la URL final, el método y el código de estado.
• He diferenciado Request Headers de Response Headers.
• He revisado HSTS en la respuesta HTTPS.
• He distinguido CSP aplicada de CSP Report-Only.
• He comprobado X-Content-Type-Options y el tipo MIME de varios recursos.
• He comparado Referrer-Policy con peticiones donde puede intervenir.
• He interpretado Permissions-Policy según las funciones reales de la aplicación.
• He revisado redirecciones, páginas interiores y respuestas de error.
• He repetido la prueba sin caché cuando era necesario.
• He formulado las conclusiones con el alcance exacto de las respuestas observadas.

Preguntas frecuentes

¿Puedo comprobar las cabeceras sin ser propietario de la web?

Puedes observar mediante DevTools las cabeceras recibidas al acceder normalmente a una URL pública. Las pruebas activas, el acceso a zonas privadas y cualquier cambio de configuración requieren la autorización correspondiente.

¿Es mejor DevTools o un comprobador online?

DevTools aporta contexto sobre cada recurso, redirección y mensaje de consola. Un comprobador externo puede ofrecer una segunda observación desde otra infraestructura, pero sus resultados deben compararse usando la misma URL y el mismo tipo de respuesta.

¿Todas las páginas deben devolver las mismas cabeceras?

No necesariamente. Las políticas pueden variar según el contenido y la función de cada ruta. Sin embargo, una diferencia inesperada debe investigarse porque puede proceder de servidores, aplicaciones, proxies o configuraciones distintas.

¿Tener Content-Security-Policy evita todos los ataques XSS?

No. Su eficacia depende de las directivas utilizadas y debe acompañarse de controles como la validación de datos, la codificación de salida y otras defensas de la aplicación.

¿Por qué una herramienta dice que falta una cabecera que aparece en DevTools?

Puede consultar otra URL final, recibir una respuesta distinta de la CDN, utilizar otra ubicación o seguir las redirecciones de forma diferente. Compara la URL, el estado HTTP, el recurso y el valor exacto antes de interpretar la discrepancia.

¿Una sola carga sirve como auditoría completa?

No. Solo acredita las respuestas observadas durante esa navegación. Una evaluación más amplia debe revisar las rutas, estados, recursos y contextos incluidos en su alcance.