Para comprobar las cabeceras de seguridad de una web, pide la página por HTTPS y revisa seis encabezados de respuesta: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options (o frame-ancestors dentro de la CSP), X-Content-Type-Options, Referrer-Policy y Permissions-Policy, además de los atributos de cada Set-Cookie. Que falte una cabecera no es siempre un agujero, y que esté no garantiza nada: lo que cuenta es el valor. Nuestra consulta de encabezados HTTP gratis te muestra todas las cabeceras de una URL en segundos, sin crear cuenta.
Todos los resultados de esta guía salieron de pruebas reales hechas el 3 de noviembre de 2026 con nuestra herramienta sobre GitHub, la BBC y example.com. Las reglas vienen de MDN, de los requisitos oficiales de la lista de precarga HSTS y del RFC 6797, revisados ese mismo día.
¿Ya tienes la URL? Pega la dirección completa, con https://, en la herramienta gratuita de encabezados HTTP y deja el resultado abierto mientras repasas la lista de abajo.
Las seis cabeceras que importan y qué valor deberían tener
| Cabecera | Qué evita | Un valor sólido | Error típico |
|---|---|---|---|
Strict-Transport-Security | Que te bajen a HTTP sin cifrar y te roben la cookie en un Wi-Fi público | max-age=31536000; includeSubDomains | Un max-age corto, o enviarla solo en la redirección HTTP |
Content-Security-Policy | Scripts inyectados (XSS) y fuga de datos | Empieza en default-src 'self' o 'none' y enumera los orígenes reales | 'unsafe-inline' en script-src, o comodines |
X-Frame-Options / frame-ancestors | Clickjacking (tu página metida en un iframe ajeno) | DENY, SAMEORIGIN o frame-ancestors 'self' | Olvidarla en el login o en la página de pago |
X-Content-Type-Options | Que el navegador "adivine" que un archivo de texto es un script | nosniff (el único valor válido) | Ninguno: es una palabra |
Referrer-Policy | Filtrar URLs completas, tokens y búsquedas a otros sitios | strict-origin-when-cross-origin o más estricta | Poner la antigua no-referrer-when-downgrade |
Permissions-Policy | Que un tercero incrustado use cámara, micrófono o ubicación | camera=(), microphone=(), geolocation=() si no los usas | Omitirla en páginas llenas de widgets externos |
Una que ya puedes olvidar: X-XSS-Protection. MDN advierte que puede crear vulnerabilidades XSS en webs que de otro modo serían seguras y recomienda usar una Content-Security-Policy. Por eso GitHub envía x-xss-protection: 0: apaga a propósito ese filtro antiguo.
Cómo revisar las cabeceras de seguridad paso a paso
1. Usa la URL exacta a la que llega la gente
Escribe la dirección completa con el esquema: https://github.com/, no github.com. Cuando probamos el dominio pelado, la herramienta respondió con un aviso de campo obligatorio en lugar de un resultado, porque necesita el esquema para saber qué pedir. Revisa la portada, pero también el login, los formularios y el pago: muchas veces los sirve otra aplicación con otras cabeceras.
2. Lanza la consulta
Abre la consulta de encabezados HTTP, pega la URL y pulsa el botón. La petición sale de nuestro servidor, así que ves lo mismo que recibe cualquier visitante, sin extensiones ni caché de tu navegador de por medio. Es gratis y no pide cuenta; sin registrarte tienes 5 consultas al día, y una cuenta gratuita (sin spam) quita ese límite.
3. Localiza el salto que te interesa
La herramienta sigue las redirecciones y junta en una sola tabla las cabeceras de todos los saltos. La primera fila muestra el estado de la primera respuesta. Al consultar http://github.com, la tabla empezó con HTTP/1.1 301 Moved Permanently y Location: https://github.com/, y todo lo que venía después era de la página HTTPS final. La regla: lo que aparece debajo de la última fila Location es lo que recibe la página que la gente ve. Para una tabla limpia, consulta directamente la URL HTTPS final y usa el verificador de redirecciones para ver el código de cada salto.
4. Compara cada cabecera con la tabla
Recorre las seis filas de arriba. Anota lo que falta y luego lee el valor de lo que sí está, porque un valor flojo es un problema más frecuente que una cabecera ausente.
5. Mira los atributos de las cookies
Todas las líneas Set-Cookie salen juntas en una fila. Una cookie de sesión debería llevar Secure, HttpOnly y un valor SameSite. Una cookie de analítica puede no llevar HttpOnly a propósito, porque los scripts tienen que leerla.
Ejemplo 1: GitHub, la referencia fuerte
La consulta de https://github.com/ devolvió HTTP/2 200 y estas filas de seguridad (CSP recortada):
strict-transport-security: max-age=31536000; includeSubdomains; preload
x-frame-options: deny
x-content-type-options: nosniff
x-xss-protection: 0
referrer-policy: origin-when-cross-origin, strict-origin-when-cross-origin
content-security-policy: default-src 'none'; base-uri 'self'; child-src github.githubassets.com ...- La CSP parte de
default-src 'none': no se carga nada que una directiva no permita. Es el punto de partida más estricto y el que conviene copiar en un sitio nuevo. - La Referrer-Policy es una lista. MDN lo documenta como política de respaldo: el navegador aplica el último valor que entiende, así que los navegadores actuales usan
strict-origin-when-cross-origin. - Cada cookie tiene los atributos que pide su función.
_gh_sessylogged_inllevanHttpOnly; secure; SameSite=Lax;_octollevasecure; SameSite=LaxsinHttpOnly, lógico para un valor que leen los scripts.
No hay Permissions-Policy. Ni siquiera los sitios muy cuidados envían todo, así que usa la lista como guía, no como nota.
Ejemplo 2: la BBC, cabeceras presentes pero flojas
La consulta de https://www.bbc.com/ mostró:
referrer-policy: no-referrer-when-downgrade
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
strict-transport-security: max-age=31536000; preloadA simple vista, cuatro de seis. Leyendo con calma salen dos problemas reales:
- La política de referrer es más débil que la del propio navegador. Según MDN, si no se define ninguna, el navegador usa
strict-origin-when-cross-origin, yno-referrer-when-downgradeera el valor por defecto anterior. Al fijar el valor viejo, el navegador manda la URL completa, con ruta y parámetros, a cualquier otro sitio HTTPS; sin la cabecera mandaría solo el dominio. - Pide entrar en la lista de precarga HSTS pero no cumple. hstspreload.org exige
includeSubDomainsjunto conpreloady un max-age de al menos un año en el dominio base. También probamoshttps://bbc.com/: responde con un 301 hacia www y el mismomax-age=31536000; preload, sinincludeSubDomains.
Tampoco hay Content-Security-Policy. En una página con anuncios y muchos scripts de terceros es el hueco más grande, y también el más difícil de cerrar.
Ejemplo 3: example.com, nada de nada
https://example.com/ devolvió HTTP/2 200 con fecha, tipo de contenido, server: cloudflare, filas de caché y ninguna cabecera de seguridad. Pedido por http:// desde nuestro servidor, respondió HTTP/1.1 200 OK sin redirigir a HTTPS. En una web real sería lo primero que arreglar; en una página estática de documentación sin login, cookies ni formularios, el riesgo es bajo. Esa es la regla del contexto: no es lo mismo que falte la CSP en una página informativa que en el checkout de una tienda.
Errores que hacen engañosa la revisión
- HSTS en la redirección HTTP no cuenta. MDN y el RFC 6797 indican que el navegador ignora
Strict-Transport-Securityrecibida por HTTP sin cifrar. El saltohttp://de GitHub solo envía el 301 yLocation; la cabecera llega con la página HTTPS, que es lo correcto. - Un 302 de HTTP a HTTPS funciona, pero un 301 es más limpio.
http://www.bbc.com/respondió302 Foundyhttp://github.com/,301. Los dos llegan a HTTPS; HSTS es lo que elimina esa primera petición insegura en las visitas siguientes. Lo explicamos en la guía para saber si una redirección es 301 o 302. Content-Security-Policy-Report-Onlyno bloquea nada. Solo informa: el sitio está probando una política, no protegido por ella.- La CDN puede añadir o quitar cabeceras. Si tu servidor las pone y la consulta no las muestra, revisa las reglas de la CDN antes de culpar a la aplicación.
- Una metaetiqueta no es una cabecera. Una CSP puesta con
<meta http-equiv>no aparece en esta consulta y no admiteframe-ancestors. Para ver lo que hay en el HTML usa el verificador de metaetiquetas. - Unas buenas cabeceras no prueban que la web sea de fiar. Una página de phishing puede enviarlas perfectas. Para juzgar un sitio desconocido sigue nuestra guía para saber si una página web es confiable y revisa el certificado con la consulta SSL.
Un punto de partida razonable para tu web
Para un sitio típico servido solo por HTTPS, esta es una primera versión segura. Pruébala en una copia de pruebas y despliega la CSP primero como Report-Only:
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
Content-Security-Policy: default-src 'self'; frame-ancestors 'self'; object-src 'none'; base-uri 'self'Añade includeSubDomains solo cuando todos los subdominios funcionen por HTTPS, y no pongas preload hasta estar seguro, porque salir de la lista de precarga es lento. Después vuelve a pasar la URL por la consulta de encabezados gratis y confirma que cada línea llegó tal cual.
Preguntas frecuentes
¿Cómo compruebo las cabeceras de seguridad gratis?
Pega la URL completa, con https://, en la consulta de encabezados HTTP de My Botsy. Muestra todas las cabeceras de respuesta en segundos y sin cuenta. También puedes usar curl -sI seguido de la URL en una terminal, o abrir las herramientas de desarrollo del navegador, pestaña Red, y hacer clic en la petición de la página.
¿Qué cabeceras de seguridad debería tener toda web?
Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options con nosniff, una Referrer-Policy y protección contra iframes con X-Frame-Options o frame-ancestors. Permissions-Policy vale la pena si incrustas contenido de terceros. X-XSS-Protection está obsoleta: ponla a 0 o no la envíes.
¿Por qué la consulta muestra primero un 301?
Porque sigue las redirecciones y junta todos los saltos en una tabla; la primera fila es el estado de la primera respuesta. Lo que va después de la última fila Location pertenece a la página final. Consulta directamente la URL HTTPS final si quieres un resultado limpio.
¿Una web sin Content-Security-Policy es insegura?
No necesariamente. La CSP limita el daño si alguien consigue inyectar un script. Una página estática sin login, formularios ni scripts de terceros tiene poco que proteger; un login o un checkout sin CSP sí tiene un hueco real.
¿Puedo añadir cabeceras de seguridad sin acceso al servidor?
Muchas veces sí. Las CDN como Cloudflare permiten añadir cabeceras de respuesta con reglas, y muchos hostings dejan definirlas en el .htaccess o en el panel. La CSP también puede ir en una metaetiqueta, pero frame-ancestors solo funciona como cabecera real.
¿Las cabeceras de seguridad ayudan al SEO?
Su función es proteger a los visitantes, no posicionar, así que no esperes un salto de tráfico por añadirlas. Lo que sí aportan es confianza y coherencia: HSTS mantiene en HTTPS a quien vuelve, y una redirección limpia de HTTP a HTTPS hace que los buscadores vean una sola versión de cada página.
