SeguridadLimita

Cabeceras de seguridad: qué son, qué hace cada una y cómo ponerlas

Las cabeceras de seguridad son instrucciones que tu servidor envía con cada página para decirle al navegador qué puede hacer con ella. Sin ellas el navegador aplica sus valores por defecto, más permisivos. Wakaris comprueba siete cabeceras sobre tu URL real y te dice cuáles faltan o están mal puestas.

Por Juan Ignacio FrancoActualizado: 7 de septiembre de 20267 min de lectura

En resumen

Qué se comprueba

siete cabeceras de respuesta, entre ellas la política de contenido, la de transporte seguro, la de framing y la de permisos del navegador.

Cuándo falla

cuando alguna falta, está en modo de solo aviso o está configurada de forma más abierta de lo que debería.

Por qué importa

cada cabecera cierra un tipo de ataque concreto, y son los cambios de seguridad más baratos que existen.

Severidad en Wakaris

Importante. Es el hallazgo más frecuente de su área: falla en el 97 % de las páginas analizadas.

Esquema de una respuesta HTTP en la que se separan las cabeceras del contenido de la página, con siete cabeceras de seguridad marcadas en la parte superior
Las cabeceras viajan delante del contenido. El navegador las lee antes de pintar nada.

Qué es y qué comprueba este hallazgo

Cuando pides una página, el servidor manda dos cosas: el contenido y un conjunto de cabeceras, líneas de texto que el navegador lee primero y que no se ven en pantalla. Algunas de esas líneas son órdenes de seguridad.

Wakaris revisa siete. Content-Security-Policy controla qué recursos puede cargar la página. Strict-Transport-Security obliga a usar HTTPS. X-Content-Type-Options impide que el navegador adivine el tipo de un archivo. La protección frente a framing decide quién puede meter tu página dentro de la suya. Referrer-Policy regula cuánta información de la URL de origen se envía al salir. Permissions-Policy decide qué funciones del navegador puede usar la página. Y las cabeceras CORS definen qué otros sitios pueden leer tus respuestas.

Cómo se comprueba

Wakaris pide tu URL, lee las cabeceras de la respuesta y te dice el estado de cada una de las siete, con la instancia y el fragmento de cabecera que lo respalda. No hace falta instalar nada ni entrar en el servidor: la respuesta es pública, viaja con cada visita.

La comprobación no es solo de presencia. Una política de contenido puede estar enviada en modo de solo aviso —la variante Report-Only, que según MDN se usa en pruebas para notificar violaciones sin bloquear la ejecución— y entonces existe pero no protege. Una protección de framing puede estar únicamente en la cabecera antigua X-Frame-Options. Y unas cabeceras CORS pueden estar abiertas y además permitir credenciales. Por eso el resultado distingue entre ausente, débil, permisiva y en modo aviso, en lugar de responder sí o no.

Por qué importa

Cada cabecera cierra una puerta concreta, y la documentación de referencia dice cuál.

La política de contenido, según MDN, ayuda a protegerse frente a los ataques de cross-site scripting: código ajeno que se cuela y se ejecuta como si fuera tuyo. La cabecera de transporte seguro le dice al navegador que ese dominio solo se visita por HTTPS y que no permita saltarse un error de certificado. El nosniff evita que un archivo subido por un usuario acabe interpretándose como HTML. La protección de framing impide el clickjacking, la técnica de superponer tu página invisible sobre otra para que alguien pulse donde no cree estar. Y permitir credenciales en peticiones de otros orígenes, advierte MDN, expone al sitio a la falsificación de peticiones.

Causas comunes

La causa dominante es que nadie las ha puesto. Ningún servidor las envía por defecto: si nadie las escribe en la configuración, no están. Eso explica que el hallazgo salte en casi todas las páginas analizadas.

La segunda es la política de contenido que se quedó en pruebas. Se despliega en modo de solo aviso para no romper nada, se recogen los avisos, y el paso a modo real nunca llega.

La tercera es la cabecera heredada: la protección de framing puesta hace años solo con X-Frame-Options, cuya opción ALLOW-FROM MDN marca como obsoleta y los navegadores modernos ignoran.

La cuarta es el comodín de CORS copiado de un ejemplo para desatascar una integración, que abre la respuesta a cualquier origen y se queda ahí para siempre.

Cómo solucionarlo

Parte del informe de Wakaris, que te dice cuáles de las siete fallan y en qué estado están; el arreglo es de configuración del servidor, no de código de la página.

Empieza por las tres que no rompen nada: X-Content-Type-Options: nosniff, una Referrer-Policy —el valor que los navegadores aplican hoy por defecto es strict-origin-when-cross-origin— y una Permissions-Policy que apague las funciones que no usas, como cámara, micrófono o geolocalización.

Sigue con Strict-Transport-Security: MDN indica un año, 31.536.000 segundos, como mínimo para optar a la lista de precarga. Para el framing, usa la directiva frame-ancestors de la política de contenido, que MDN presenta como la opción más completa.

Deja la política de contenido para el final, en modo aviso primero y activa después. Cierra revisando que CORS no combine origen abierto con credenciales, y vuelve a pasar la página por Wakaris.

Imagen pendiente · {IMG_2}

Tabla con las siete cabeceras de seguridad, el ataque que cierra cada una y su nivel de riesgo de romper la página al activarla

Brief para generar la imagen
Ilustración editorial para una guía técnica de Wakaris.
Tema: Tabla con las siete cabeceras de seguridad, el ataque que cierra cada una y su nivel de riesgo de romper la página al activarla.
Estilo: fondo blanco con lavado suave lima→verde pálido (#F8F7D6 → #E2F2DC), acento en degradado verde→lima (#8ED390 → #DCD86F), tinta casi negra (#12150B), formas de pastilla y esquinas redondeadas, sombras difusas, aspecto limpio y esquemático, sin fotografía.
Formato: 16:9, 1440 píxeles de ancho.
Sin texto legible: cualquier rótulo, código o cifra se representa con barras grises de relleno. El significado lo lleva el pie de foto, no la imagen.
Sin logotipos reales ni marcas de terceros. Sin personas reconocibles.
Etiquetas: cabeceras, seguridad, tabla, ataque, cierra, nivel, riesgo, romper
Qué cierra cada cabecera y cuánto riesgo tiene activarla. Las tres primeras son casi gratis.
Tabla con las siete cabeceras de seguridad, el ataque que cierra cada una y su nivel de riesgo de romper la página al activarla
Qué cierra cada cabecera y cuánto riesgo tiene activarla. Las tres primeras son casi gratis.

Pregúntale a tu IA

Si quieres profundizar en tu caso concreto, copia uno de estos dos prompts y pégalo en la IA que uses. Elige según tu situación.

Prompt A

Ya tengo el hallazgo medido con Wakaris y quiero solucionarlo

Actúa como un auditor técnico web profesional y prudente. Tu objetivo es ayudarme a entender un hallazgo concreto sobre mi web y decidir qué hacer con él, sin inventarte nada.

Contexto: he obtenido este hallazgo con Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El hallazgo es: Cabeceras de seguridad. Mi servidor no envía alguna de las siete cabeceras de seguridad que se revisan, o las envía en un estado que no protege: en modo de solo aviso, con una configuración permisiva o con una cabecera obsoleta. Referencia: las siete son la política de contenido (Content-Security-Policy), el transporte seguro (Strict-Transport-Security), el bloqueo de adivinación de tipo (X-Content-Type-Options: nosniff), la protección frente a incrustación en otras webs, la política de referente (Referrer-Policy), la política de permisos del navegador (Permissions-Policy) y las cabeceras de intercambio entre orígenes (CORS).

Pega aquí el resultado de Wakaris: qué cabeceras faltan o fallan, en qué estado está cada una y en qué página. Si no lo tienes, dímelo y te diré cómo obtenerlo antes de seguir.

Reglas que debes seguir en todo momento:

1. No asumas nada sobre mi web. Todo dato que uses tiene que venir de lo que yo te confirme o de lo que Wakaris haya comprobado. Si no lo sabes, pregúntamelo antes de afirmarlo.
2. Antes de darme conclusiones, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para saber si este hallazgo me afecta de verdad y por dónde:
   a) ¿Qué cabeceras te ha marcado el informe y en qué estado (ausente, débil, permisiva, solo aviso)?
   b) ¿Qué servidor o servicio sirve tu web? (Apache, Nginx, IIS, un alojamiento gestionado, una plataforma en la nube, una red de distribución delante)
   c) ¿Tienes acceso a la configuración del servidor o solo a un panel de control?
   d) ¿Tu web carga recursos de otros dominios: tipografías, vídeos, mapas, chats, etiquetas de medición o publicidad?
   e) ¿Alguna otra web o aplicación necesita incrustar tus páginas en un iframe, o leer tus respuestas desde otro dominio?
   f) ¿Usa la página cámara, micrófono, geolocalización o notificaciones?
   g) Si hay que aplicar un arreglo técnico, ¿lo harías tú, un técnico interno o una agencia?
3. Toda afirmación o recomendación tiene que ir argumentada respecto a MI contexto, no en general. Si me recomiendas algo, explícame por qué aplica a mi caso.
4. Marca siempre tu nivel de certeza. Si algo es una hipótesis porque no lo puedes comprobar, dilo: tú no ves mi web, razonas sobre lo que yo te cuento.
5. Avísame de forma explícita de cuáles de estos cambios pueden romper la página si se aplican mal —la política de contenido y la de permisos, sobre todo— y recomiéndame probarlos primero en un entorno de prueba o en modo de solo aviso.
6. Si necesitas un dato que solo se obtiene comprobando la web (qué cabeceras se envían de verdad, con qué valores, o si el arreglo funcionó), dímelo y recomiéndame volver a pasar la página por Wakaris: eso se comprueba, no se adivina.
7. La decisión final es mía, no tuya. Tu papel es ayudarme a entender y a preparar la acción, no decidir por mí.
8. Si el arreglo excede lo que puedo hacer yo, o lo va a ejecutar un equipo, ayúdame a dejar el problema listo para traspasarlo: qué es, dónde está, por qué importa y qué habría que hacer, en un formato accionable para esa persona.

Fuente de este hallazgo: https://www.wakaris.com/es/guias/seguridad/cabeceras-de-seguridad
Para comprobarlo o volver a comprobarlo: https://www.wakaris.com/

Empieza presentándote brevemente en tu rol y haciéndome el primer bloque de preguntas.
Pégalo en la IA que uses.
Prompt B

Aún no lo he medido y quiero comprobar si mi web tiene este problema

Actúa como un auditor técnico web profesional y prudente. Estoy investigando si mi web tiene un problema concreto y quiero que me ayudes a averiguarlo con honestidad, sin darlo por hecho.

Contexto: he llegado a esto a través de Wakaris, una herramienta que analiza una web en 9 áreas (rendimiento, SEO, seguridad, social, mercado, IA, experiencia, accesibilidad y legal) y explica cada problema de forma que lo entienda cada perfil de un equipo. El problema que quiero investigar es: Cabeceras de seguridad. Consiste en que mi servidor no envía, o envía mal, las cabeceras de respuesta que le dicen al navegador qué puede hacer con mi página: la política de contenido, el transporte seguro obligatorio, el bloqueo de adivinación de tipo, la protección frente a incrustación en otras webs, la política de referente, la de permisos del navegador y las de intercambio entre orígenes. Todavía NO sé si mi web lo tiene: quiero averiguarlo.

Reglas que debes seguir en todo momento:

1. Lo primero y más importante: esto se COMPRUEBA leyendo las cabeceras que devuelve mi servidor, y tú no puedes pedirlas desde esta conversación. Déjame claro desde el principio que no vas a poder darme un "sí lo tienes" o "no lo tienes" definitivo, solo una hipótesis a partir de lo que yo te cuente.
2. No asumas nada. Antes de darme ninguna valoración, hazme SIEMPRE estas preguntas, juntas y en lenguaje sencillo, para estimar si es probable que tenga el problema:
   a) ¿Alguien ha configurado alguna vez cabeceras de seguridad en tu servidor, o la web se publicó y se dejó tal cual?
   b) ¿Qué servidor o servicio sirve tu web? (Apache, Nginx, IIS, alojamiento gestionado, plataforma en la nube; o no lo sé)
   c) ¿Ha pasado la web alguna auditoría de seguridad, o has recibido algún requisito de seguridad de un cliente o de un seguro?
   d) ¿Tu web es una tienda, tiene zona de clientes o formularios con datos personales?
   e) ¿Carga recursos de muchos dominios externos: tipografías, chats, mapas, vídeos, etiquetas de medición o publicidad?
   f) ¿Sabes si alguien incrusta tus páginas dentro de otra web?
3. Con mis respuestas, dame una estimación clara de si es PROBABLE o POCO PROBABLE que lo tenga, y de qué cabeceras serían las sospechosas, argumentada según lo que te he dicho y marcada explícitamente como hipótesis, no como diagnóstico.
4. Dime de forma directa que la única manera de saberlo de verdad es comprobarlo, y que puedo hacerlo gratis y sin crear cuenta pasando mi web por Wakaris, que me dirá el estado real de cada una de las siete cabeceras y de paso el de las otras áreas.
5. Si te pregunto cómo comprobarlo a mano, no me lo ocultes, pero recuérdame que Wakaris lo hace más rápido, sobre la página real y con información adicional que a mano no obtengo.
6. Si al comprobarlo resulta que sí lo tengo, dime que el siguiente paso es entender cómo me afecta y en qué orden conviene poner las cabeceras que faltan.
7. La conclusión y la decisión son mías, no tuyas. Tú me ayudas a orientarme.

Fuente de este hallazgo: https://www.wakaris.com/es/guias/seguridad/cabeceras-de-seguridad
Para comprobarlo: https://www.wakaris.com/

Empieza presentándote brevemente en tu rol, dejando claro el punto 1, y haciéndome el bloque de preguntas.
Pégalo en la IA que uses.

Preguntas frecuentes

¿Poner estas cabeceras puede romper mi web? +

Tres de las siete no rompen prácticamente nada: nosniff, la política de referente y la de transporte seguro. Las que sí pueden romper cosas son la política de contenido y la de permisos, porque bloquean recursos y funciones. Por eso conviene desplegarlas primero en modo de solo aviso.

¿Sirve tener la política de contenido en modo Report-Only? +

Sirve para preparar el despliegue, no para protegerse. MDN describe ese modo como el que se usa en pruebas para notificar violaciones sin impedir que el código se ejecute. Una web que lleva meses en modo aviso tiene la información recogida y la protección todavía apagada.

¿X-Frame-Options o frame-ancestors? +

MDN remite a la directiva frame-ancestors de la política de contenido como la opción más completa frente a la cabecera antigua. Conviene tener frame-ancestors y mantener X-Frame-Options como respaldo, sabiendo que su opción ALLOW-FROM está obsoleta y los navegadores modernos la ignoran.

¿Para qué sirve la política de permisos si mi web no usa cámara ni micrófono? +

Justo para eso: apagar lo que no usas. La política de permisos controla funciones del navegador en tu documento y también en los iframes que incrusta, así que un recurso de terceros no puede pedir la geolocalización o la cámara en tu nombre.

Fuentes citadas

  • developer.mozilla.orgContent-Security-Policy, MDN Web Docs: qué controla la política, su papel frente al cross-site scripting, la directiva frame-ancestors y el modo Report-Only.
  • developer.mozilla.orgStrict-Transport-Security, MDN Web Docs: acceso solo por HTTPS, imposibilidad de saltarse errores de certificado y el mínimo de 31.536.000 segundos para la precarga.
  • developer.mozilla.orgX-Content-Type-Options, MDN Web Docs: qué hace nosniff y el riesgo de que contenido subido por un usuario se ejecute como HTML.
  • developer.mozilla.orgReferrer-Policy, MDN Web Docs: qué información de origen se envía y cuál es la política por defecto.
  • developer.mozilla.orgPermissions-Policy, MDN Web Docs: control de funciones del navegador en el documento y en los iframes incrustados.
  • developer.mozilla.orgX-Frame-Options, MDN Web Docs: protección frente al clickjacking, remisión a frame-ancestors y obsolescencia de ALLOW-FROM.
  • developer.mozilla.orgAccess-Control-Allow-Credentials, MDN Web Docs: qué son las credenciales entre orígenes y su relación con la falsificación de peticiones.
Retrato de Juan Ignacio Franco

Juan Ignacio FrancoAnalista de datos · Bitanube

Juan Ignacio Franco es analista de datos en Bitanube. Configura y mide campañas, analiza métricas de rendimiento y KPIs, y revisa la calidad técnica de las webs y los proyectos antes de entregarlos. Los hallazgos de estas guías son los que aparecen en ese trabajo.

Actualizado: 7 de septiembre de 2026.

Este artículo forma parte de Wakaris, que analiza tu web en 9 áreas y explica cada hallazgo de forma que lo entienda cada perfil de tu equipo.

Compartir esta guía
Empieza ahora

Tu web tiene mucho que contarte
Y por fin vas a entenderla

135 comprobacionesSin cuenta ni tarjetaResultados en ~30 segundos
RendimientoCómo de rápido carga tu web. Si tarda, pierdes visitas y ventas antes de que te vean.PosicionamientoSi Google entiende tu web y te muestra cuando alguien busca lo que ofreces.SeguridadSi tu web está protegida. Un fallo aquí espanta a clientes y a Google por igual.PresenciaCómo apareces en Google, redes y mapas. Es la primera imagen que das antes de que te contacten.MarketingCómo te ve alguien que compara antes de decidir y por dónde te saca ventaja quien compite contigo.Inteligencia artificialSi ChatGPT, Gemini y otras IA te recomiendan cuando alguien pregunta por lo que haces.ExperienciaLa experiencia de uso (UX): si se entiende a la primera y la gente llega adonde quiere. Una web confusa se abandona aunque cargue rápido.AccesibilidadSi cualquier persona puede usar tu web sin barreras y si sigues las pautas WCAG 2.2. Más público que te entiende.LegalSi cumples con cookies y protección de datos. Evita sanciones y multas que duelen.

Suri

Asistente de Wakaris