Referencia rápida de los encabezados de seguridad

Obtén más información sobre los encabezados que pueden proteger tu sitio y busca rápidamente los detalles más importantes.

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas

En este artículo, se enumeran los encabezados de seguridad más importantes que puedes usar para proteger tu sitio web. Úsalo para comprender las funciones de seguridad basadas en la Web, aprender a implementarlas en tu sitio web y como referencia cuando necesites un recordatorio.

Encabezados de seguridad recomendados para sitios web que manejan datos sensibles del usuario:
Política de Seguridad del Contenido (CSP)
Trusted Types
Encabezados de seguridad recomendados para todos los sitios web:
X-Content-Type-Options
X-Frame-Options
Cross-Origin Resource Policy (CORP)
Cross-Origin Opener Policy (COOP)
HTTP Strict Transport Security (HSTS)
Encabezados de seguridad para sitios web con capacidades avanzadas:
Uso compartido de recursos entre dominios (CORS)
Política de recursos integrados entre dominios (COEP)
Amenazas conocidas en la Web
Antes de profundizar en los encabezados de seguridad, obtén información sobre las amenazas conocidas en la Web y por qué deberías usar estos encabezados de seguridad.

Antes de profundizar en los encabezados de seguridad, obtén información sobre las amenazas conocidas en la Web y por qué deberías usar estos encabezados de seguridad.

Protege tu sitio de las vulnerabilidades por inyección

Las vulnerabilidades de inyección surgen cuando los datos no confiables que procesa tu aplicación pueden afectar su comportamiento y, por lo general, provocar la ejecución de secuencias de comandos controladas por el atacante. La vulnerabilidad más común causada por errores de inyección es la secuencia de comandos entre sitios (XSS) en sus diversas formas, incluidas la XSS reflejada, la XSS almacenada, la XSS basada en DOM y otras variantes.

Por lo general, una vulnerabilidad de XSS puede brindarle a un atacante acceso completo a los datos del usuario que procesa la aplicación y a cualquier otra información alojada en el mismo origen web.

Las defensas tradicionales contra las inyecciones incluyen el uso coherente de sistemas de plantillas HTML con escape automático, evitar el uso de APIs de JavaScript peligrosas y procesar correctamente los datos del usuario alojando las cargas de archivos en un dominio independiente y limpiando el código HTML controlado por el usuario.

  • Usa la Política de Seguridad del Contenido (CSP) para controlar qué secuencias de comandos puede ejecutar tu aplicación y mitigar el riesgo de inyecciones.
  • Usa Trusted Types para aplicar la limpieza de los datos que se pasan a las APIs de JavaScript peligrosas.
  • Usa X-Content-Type-Options para evitar que el navegador interprete de forma incorrecta los tipos de MIME de los recursos de tu sitio web, lo que puede provocar la ejecución de secuencias de comandos.

Aísla tu sitio de otros sitios web

La apertura de la Web permite que los sitios web interactúen entre sí de formas que pueden incumplir las expectativas de seguridad de una aplicación. Esto incluye realizar solicitudes autenticadas de forma inesperada o incorporar datos de otra aplicación en el documento del atacante, lo que le permite modificar o leer los datos de la aplicación.

Las vulnerabilidades comunes que socavan el aislamiento web incluyen el clickjacking, la falsificación de solicitudes entre sitios (CSRF), la inclusión de secuencias de comandos entre sitios (XSSI) y varias fugas entre sitios.

Post-Spectre Web Development es una excelente lectura si te interesan estos encabezados.

Crea un sitio web potente de forma segura

Spectre hace que cualquier dato cargado en el mismo grupo de contextos de navegación sea potencialmente legible a pesar de la política del mismo origen. Los navegadores restringen las funciones que podrían aprovechar la vulnerabilidad detrás de un entorno especial llamado "aislamiento de origen cruzado". Con el aislamiento de origen cruzado, puedes usar funciones potentes, como SharedArrayBuffer.

Encripta el tráfico a tu sitio

Los problemas de encriptación aparecen cuando una aplicación no encripta por completo los datos en tránsito, lo que permite que los atacantes que escuchan a escondidas conozcan las interacciones del usuario con la aplicación.

El cifrado insuficiente puede surgir en los siguientes casos: no usar HTTPS, contenido mixto, configurar cookies sin el atributo Secure (o el prefijo __Secure) o lógica de validación de CORS laxa.

Política de Seguridad del Contenido (CSP)

La secuencia de comandos entre sitios (XSS) es un ataque en el que una vulnerabilidad en un sitio web permite que se inyecte y ejecute una secuencia de comandos maliciosa.

Content-Security-Policy proporciona una capa adicional para mitigar los ataques de XSS, ya que restringe qué secuencias de comandos puede ejecutar la página.

Se recomienda que habilites la CSP estricta con uno de los siguientes enfoques:

  • Si renderizas tus páginas HTML en el servidor, usa una CSP estricta basada en nonce.
  • Si tu HTML debe entregarse de forma estática o almacenarse en caché, por ejemplo, si se trata de una aplicación de una sola página, usa una CSP estricta basada en hash.

Ejemplo de uso: Una CSP basada en nonces

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';
Cómo usar CSP

1. Usa una CSP estricta basada en nonce {: #nonce-based-csp}

Si renderizas tus páginas HTML en el servidor, usa una CSP estricta basada en nonce.

Genera un nuevo valor de nonce de secuencia de comandos para cada solicitud del servidor y establece el siguiente encabezado:

archivo de configuración del servidor

Content-Security-Policy:
  script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

En HTML, para cargar las secuencias de comandos, establece el atributo nonce de todas las etiquetas <script> en la misma cadena {RANDOM1}.

index.html

<script nonce="{RANDOM1}" src="https://example.com/script1.js"></script>
<script nonce="{RANDOM1}">
  // Inline scripts can be used with the <code>nonce</code> attribute.
</script>

Google Fotos es un buen ejemplo de una CSP estricta basada en nonce. Usa DevTools para ver cómo se usa.

2. Usa una CSP estricta basada en hash {: #hash-based-csp}

Si tu HTML debe publicarse de forma estática o almacenarse en caché, por ejemplo, si compilas una aplicación de una sola página, usa una CSP estricta basada en hash.

archivo de configuración del servidor

Content-Security-Policy:
  script-src 'sha256-{HASH1}' 'sha256-{HASH2}' 'strict-dynamic' https: 'unsafe-inline';
  object-src 'none';
  base-uri 'none';

En HTML, deberás insertar tus secuencias de comandos en línea para aplicar una política basada en hash, ya que la mayoría de los navegadores no admiten el hash de secuencias de comandos externas.

index.html

<script>
...// your script1, inlined
</script>
<script>
...// your script2, inlined
</script>

Para cargar secuencias de comandos externas, lee "Carga secuencias de comandos de origen de forma dinámica" en la sección Opción B: Encabezado de respuesta de CSP basado en hash.

CSP Evaluator es una buena herramienta para evaluar tu CSP y, al mismo tiempo, un buen ejemplo de CSP estricta basada en nonce. Usa DevTools para ver cómo se usa.

Navegadores compatibles

Otros aspectos que debes tener en cuenta sobre el CSP

  • La directiva frame-ancestors protege tu sitio del secuestro de clics, un riesgo que surge si permites que sitios no confiables incorporen el tuyo. Si prefieres una solución más simple, puedes usar X-Frame-Options para bloquear la carga, pero frame-ancestors te brinda una configuración avanzada para permitir solo orígenes específicos como incorporadores.
  • Es posible que hayas usado una CSP para asegurarte de que todos los recursos de tu sitio se carguen a través de HTTPS. Esto se ha vuelto menos relevante, ya que, hoy en día, la mayoría de los navegadores bloquean el contenido mixto.
  • También puedes establecer una CSP en modo de solo informe.
  • Si no puedes establecer una CSP como encabezado del servidor, también puedes establecerla como una metaetiqueta. Ten en cuenta que no puedes usar el modo solo informe para las etiquetas meta (aunque esto puede cambiar).

Más información

Trusted Types

El XSS basado en el DOM es un ataque en el que se pasan datos maliciosos a un receptor que admite la ejecución de código dinámico, como eval() o .innerHTML.

Trusted Types proporciona las herramientas para escribir, revisar la seguridad y mantener aplicaciones sin XSS del DOM. Se pueden habilitar a través de la CSP y hacen que el código JavaScript sea seguro de forma predeterminada, ya que limitan las APIs web peligrosas para que solo acepten un objeto especial: un tipo de confianza.

Para crear estos objetos, puedes definir políticas de seguridad en las que te asegures de que las reglas de seguridad (como el escape o la sanitización) se apliquen de forma coherente antes de que los datos se escriban en el DOM. Por lo tanto, estas políticas son los únicos lugares en el código que podrían introducir XSS del DOM.

Ejemplos de uso

Content-Security-Policy: require-trusted-types-for 'script'

// Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');
    }
  });
}


// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.

// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;&lt;img src=x onerror=alert(1)&gt;&#39;);
el.innerHTML = escaped;  // &#39;&amp;lt;img src=x onerror=alert(1)&amp;gt;&#39;
Cómo usar Trusted Types

  1. Aplica Trusted Types para los receptores DOM peligrosos Encabezado de CSP y Trusted Types: 

    Content-Security-Policy: require-trusted-types-for 'script'

    Actualmente, 'script' es el único valor aceptable para la directiva require-trusted-types-for.

    Por supuesto, puedes combinar Trusted Types con otras directivas de la CSP:

Combinación de una CSP basada en nonce del ejemplo anterior con Trusted Types: 

Content-Security-Policy:
  script-src &#39;nonce-{RANDOM1}&#39; &#39;strict-dynamic&#39; https: &#39;unsafe-inline&#39;;
  object-src &#39;none&#39;;
  base-uri &#39;none&#39;;
  require-trusted-types-for &#39;script&#39;;




<aside class="note"><b>Nota: </b> Puedes limitar los nombres de políticas de Trusted Types permitidos configurando una directiva <code>trusted-types</code> adicional (por ejemplo, <code>trusted-types myPolicy</code>). Sin embargo, esto no es un requisito.</aside>  </aside>


    
  
  1. 
    
    Cómo definir una política
    
    
    Política:
    
    
    // Feature detection
if (window.trustedTypes && trustedTypes.createPolicy) {
  // Name and create a policy
  const policy = trustedTypes.createPolicy('escapePolicy', {
    createHTML: str => {
      return str.replace(/\/g, '>');
    }
  });
}
    
    
  
    2. 
  
  2. 
    
    Aplica la política
    
    
    Usa la política cuando escribas datos en el DOM:
    
    
    // Assignment of raw strings are blocked by Trusted Types.
el.innerHTML = &#39;some string&#39;; // This throws an exception.</p>

<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML(&#39;<img src="x" onerror="alert(1)">&#39;);
el.innerHTML = escaped;  // &#39;&lt;img src=x onerror=alert(1)&gt;&#39;
    
    
    Con require-trusted-types-for 'script', usar un tipo seguro es un requisito. Si usas cualquier API de DOM peligrosa con una cadena, se producirá un error.
    
  
    3. 



Navegadores compatibles



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


Más información

X-Content-Type-Options

Cuando se publica un documento HTML malicioso desde tu dominio (por ejemplo, si una imagen subida a un servicio de fotos contiene un lenguaje de marcado HTML válido), algunos navegadores lo tratarán como un documento activo y permitirán que ejecute secuencias de comandos en el contexto de la aplicación, lo que generará un error de secuencias de comandos entre sitios.

X-Content-Type-Options: nosniff lo evita indicándole al navegador que el tipo de MIME establecido en el encabezado Content-Type para una respuesta determinada es correcto. Se recomienda este encabezado para todos tus recursos.

Ejemplo de uso

X-Content-Type-Options: nosniff
Cómo usar X-Content-Type-Options

Se recomienda usar X-Content-Type-Options: nosniff para todos los recursos que se publican desde tu servidor junto con el encabezado Content-Type correcto.

X-Content-Type-Options: nosniff

Ejemplo de encabezados enviados con un documento HTML

X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8

Navegadores compatibles

Browser Support

  • Chrome: 64.
  • Edge: 12.
  • Firefox: 50.
  • Safari: 11.

Source

Más información

X-Frame-Options

Si un sitio web malicioso puede incorporar tu sitio como un iframe, es posible que los atacantes puedan invocar acciones no deseadas por parte del usuario con clickjacking. Además, en algunos casos, los ataques de tipo Spectre les dan a los sitios web maliciosos la oportunidad de obtener información sobre el contenido de un documento incorporado.

X-Frame-Options indica si se debe permitir que un navegador renderice una página en un <frame>, <iframe>, <embed> o <object>. Se recomienda que todos los documentos envíen este encabezado para indicar si permiten que otros documentos los incorporen.

Ejemplo de uso

X-Frame-Options: DENY
Cómo usar X-Frame-Options

Todos los documentos que no estén diseñados para incorporarse deben usar el encabezado X-Frame-Options.

Puedes probar cómo las siguientes configuraciones afectan la carga de un iframe en esta demostración. Cambia el menú desplegable X-Frame-Options y haz clic en el botón Vuelve a cargar el iframe.

Protege tu sitio web para que no se pueda incorporar en otros sitios web

Rechaza la incorporación en cualquier otro documento.

X-Frame-Options: DENY 
X-Frame-Options: DENY

Protege tu sitio web para que no se pueda incorporar en sitios web de otros orígenes

Permite la incorporación solo en documentos del mismo origen.

X-Frame-Options: SAMEORIGIN

Navegadores compatibles

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 4.

Source

Más información

Política de recursos de origen cruzado (CORP)

Un atacante puede incorporar recursos de otro origen, por ejemplo, de tu sitio, para obtener información sobre ellos aprovechando las fugas entre sitios basadas en la Web.

Cross-Origin-Resource-Policy mitiga este riesgo indicando el conjunto de sitios web en los que se puede cargar. El encabezado toma uno de tres valores: same-origin, same-site y cross-origin. Se recomienda que todos los recursos envíen este encabezado para indicar si permiten que otros sitios web los carguen.

Ejemplo de uso

Cross-Origin-Resource-Policy: same-origin
Cómo usar CORP

Se recomienda que todos los recursos se publiquen con uno de los siguientes tres encabezados.

Puedes probar cómo las siguientes configuraciones afectan la carga de recursos en un entorno de Cross-Origin-Embedder-Policy: require-corp en esta demostración. Cambia el menú desplegable Cross-Origin-Resource-Policy y haz clic en el botón Recargar el iframe o Recargar la imagen para ver el efecto.

Permitir que se carguen recursos cross-origin

Se recomienda que los servicios similares a CDN apliquen cross-origin a los recursos (ya que, por lo general, se cargan en páginas de origen cruzado), a menos que ya se publiquen a través de CORS, que tiene un efecto similar.

Cross-Origin-Resource-Policy: cross-origin 
Cross-Origin-Resource-Policy: cross-origin

Limita los recursos que se cargarán desde same-origin

same-origin se debe aplicar a los recursos que se cargan solo en páginas del mismo origen. Debes aplicar esto a los recursos que incluyen información sensible sobre el usuario o las respuestas de una API que está diseñada para llamarse solo desde el mismo origen.

Ten en cuenta que los recursos con este encabezado se pueden cargar directamente, por ejemplo, si se navega a la URL en una ventana nueva del navegador. La política de recursos de origen cruzado solo protege el recurso de la incorporación de otros sitios web.

Cross-Origin-Resource-Policy: same-origin 
Cross-Origin-Resource-Policy: same-origin

Limita los recursos que se cargarán desde same-site

Se recomienda aplicar same-site a los recursos que son similares a los anteriores, pero que están destinados a ser cargados por otros subdominios de tu sitio.

Cross-Origin-Resource-Policy: same-site 
Cross-Origin-Resource-Policy: same-site

Navegadores compatibles

Browser Support

  • Chrome: 73.
  • Edge: 79.
  • Firefox: 74.
  • Safari: 12.

Source

Más información

Política de abridor de origen cruzado (COOP)

El sitio web de un atacante puede abrir otro sitio en una ventana emergente para obtener información sobre él aprovechando las fugas entre sitios basadas en la Web. En algunos casos, esto también puede permitir la explotación de ataques de canal lateral basados en Spectre.

El encabezado Cross-Origin-Opener-Policy proporciona una forma para que un documento se aísle de las ventanas de origen cruzado que se abren a través de window.open() o un vínculo con target="_blank" sin rel="noopener". Como resultado, cualquier abridor de origen cruzado del documento no tendrá ninguna referencia a él y no podrá interactuar con él.

Ejemplo de uso

Cross-Origin-Opener-Policy: same-origin-allow-popups
Cómo usar COOP

Puedes probar cómo las siguientes configuraciones afectan la comunicación con una ventana emergente de origen cruzado en esta demostración. Cambia el menú desplegable Cross-Origin-Opener-Policy para el documento y la ventana emergente, haz clic en el botón Abrir una ventana emergente y, luego, en Enviar un postMessage para ver si el mensaje se entrega.

Aísla un documento de ventanas de origen cruzado

El parámetro de configuración same-origin aísla el documento de las ventanas de documentos de origen cruzado.

Cross-Origin-Opener-Policy: same-origin 
Cross-Origin-Opener-Policy: same-origin

Aísla un documento de ventanas de origen cruzado, pero permite ventanas emergentes

Establecer same-origin-allow-popups permite que un documento conserve una referencia a sus ventanas emergentes, a menos que establezcan COOP con same-origin o same-origin-allow-popups. Esto significa que same-origin-allow-popups aún puede proteger el documento para que no se haga referencia a él cuando se abra como una ventana emergente, pero permitir que se comunique con sus propias ventanas emergentes.

Cross-Origin-Opener-Policy: same-origin-allow-popups 
Cross-Origin-Opener-Policy: same-origin-allow-popups

Permite que las ventanas de origen cruzado hagan referencia a un documento

unsafe-none es el valor predeterminado, pero puedes indicar de forma explícita que una ventana de origen cruzado puede abrir este documento y conservar el acceso mutuo.

Cross-Origin-Opener-Policy: unsafe-none 
Cross-Origin-Opener-Policy: unsafe-none

Patrones de informes incompatibles con COOP

Puedes recibir informes cuando COOP impide las interacciones entre ventanas con la API de Reporting.

Cross-Origin-Opener-Policy: same-origin; report-to="coop"

COOP también admite un modo de solo informes para que puedas recibir informes sin bloquear la comunicación entre documentos de diferentes orígenes.

Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"

Navegadores compatibles

Browser Support

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

Source

Más información

Uso compartido de recursos entre dominios (CORS)

A diferencia de otros elementos de este artículo, el uso compartido de recursos entre dominios (CORS) no es un encabezado, sino un mecanismo del navegador que solicita y permite el acceso a recursos entre dominios.

De forma predeterminada, los navegadores aplican la política de mismo origen para evitar que una página web acceda a recursos de otros orígenes. Por ejemplo, cuando se carga una imagen de origen cruzado, aunque se muestre visualmente en la página web, el código JavaScript de la página no tiene acceso a los datos de la imagen. El proveedor de recursos puede relajar las restricciones y permitir que otros sitios web lean el recurso habilitando CORS.

Ejemplo de uso

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Cómo usar CORS

Antes de analizar cómo configurar CORS, es útil comprender la distinción entre los tipos de solicitudes. Según los detalles de la solicitud, esta se clasificará como solicitud simple o solicitud preliminar.

Criterios para una solicitud simple:

  • El método es GET, HEAD o POST.
  • Los encabezados personalizados solo incluyen Accept, Accept-Language, Content-Language y Content-Type.
  • El Content-Type es application/x-www-form-urlencoded, multipart/form-data o text/plain.

Todo lo demás se clasifica como una solicitud previa al vuelo. Para obtener más detalles, consulta Uso compartido de recursos entre dominios (CORS) - HTTP | MDN.

Solicitud simple

Cuando una solicitud cumple con los criterios de solicitud simple, el navegador envía una solicitud de origen cruzado con un encabezado Origin que indica el origen solicitante.

Ejemplo de encabezado de solicitud

Get / HTTP/1.1
Origin: https://example.com

Ejemplo de encabezado de respuesta

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin: https://example.com indica que el https://example.com puede acceder al contenido de la respuesta. Los recursos que se pueden leer en cualquier sitio pueden establecer este encabezado en *, en cuyo caso el navegador solo requerirá que la solicitud se realice sin credenciales.
  • Access-Control-Allow-Credentials: true indica que las solicitudes que incluyen credenciales (cookies) pueden cargar el recurso. De lo contrario, se rechazarán las solicitudes autenticadas, incluso si el origen solicitante está presente en el encabezado Access-Control-Allow-Origin.

Puedes probar cómo la solicitud simple afecta la carga de recursos en un entorno de Cross-Origin-Embedder-Policy: require-corp en esta demostración. Haz clic en la casilla de verificación Cross-Origin Resource Sharing y, luego, en el botón Reload the image para ver el efecto.

Solicitudes de comprobación previa

Una solicitud con verificación previa está precedida por una solicitud OPTIONS para verificar si se permite enviar la solicitud posterior.

Ejemplo de encabezado de solicitud

OPTIONS / HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
  • Access-Control-Request-Method: POST permite que se realice la siguiente solicitud con el método POST.
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type permite que el solicitante establezca los encabezados HTTP X-PINGOTHER y Content-Type en la solicitud posterior.

Ejemplo de encabezados de respuesta

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
  • Access-Control-Allow-Methods: POST, GET, OPTIONS indica que se pueden realizar solicitudes posteriores con los métodos POST, GET y OPTIONS.
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type indica que las solicitudes posteriores pueden incluir los encabezados X-PINGOTHER y Content-Type.
  • Access-Control-Max-Age: 86400 indica que el resultado de la solicitud previa a la comprobación se puede almacenar en caché durante 86,400 segundos.

Navegadores compatibles

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 3.5.
  • Safari: 4.

Source

Más información

Política de incorporaciones de origen cruzado (COEP)

Para reducir la capacidad de los ataques basados en Spectre de robar recursos de origen cruzado, se inhabilitan de forma predeterminada funciones como SharedArrayBuffer o performance.measureUserAgentSpecificMemory().

Cross-Origin-Embedder-Policy: require-corp evita que los documentos y los trabajadores carguen recursos de origen cruzado, como imágenes, secuencias de comandos, hojas de estilo, elementos iframe y otros, a menos que estos recursos habiliten explícitamente su carga a través de encabezados CORS o CORP. COEP se puede combinar conCross-Origin-Opener-Policypara habilitar el aislamiento de origen cruzado en un documento.

Usa Cross-Origin-Embedder-Policy: require-corp cuando quieras habilitar el aislamiento de origen cruzado para tu documento.

Ejemplo de uso

Cross-Origin-Embedder-Policy: require-corp
Cómo usar COEP

Ejemplos de uso

COEP toma un solo valor de require-corp. Si envías este encabezado, puedes indicarle al navegador que bloquee la carga de recursos que no habiliten CORS o CORP.

Cómo funciona COEP

Puedes probar cómo las siguientes configuraciones afectan la carga de recursos en esta demostración. Cambia el menú desplegable Cross-Origin-Embedder-Policy, el menú desplegable Cross-Origin-Resource-Policy, la casilla de verificación Solo informe, etcétera, para ver cómo afectan la carga de recursos. Además, abre la demostración del extremo de informes para ver si se informan los recursos bloqueados.

Habilita el aislamiento de origen cruzado

Habilita el aislamiento de origen cruzado enviando Cross-Origin-Embedder-Policy: require-corp junto con Cross-Origin-Opener-Policy: same-origin. 

Cross-Origin-Embedder-Policy: require-corp
Cross-Origin-Opener-Policy: same-origin

Informa los recursos incompatibles con COEP

Puedes recibir informes de recursos bloqueados a causa de COEP con la API de Reporting.

Cross-Origin-Embedder-Policy: require-corp; report-to="coep"

COEP también admite el modo solo para informes, de modo que puedes recibir informes sin bloquear realmente la carga de recursos.

Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"

Navegadores compatibles

Browser Support

  • Chrome: 83.
  • Edge: 83.
  • Firefox: 79.
  • Safari: 15.2.

Source

Más información

HTTP con Seguridad de Transporte Estricta (HSTS)

La comunicación a través de una conexión HTTP sin formato no está encriptada, lo que hace que los datos transferidos sean accesibles para los intrusos a nivel de la red.

El encabezado Strict-Transport-Security informa al navegador que nunca debe cargar el sitio con HTTP y que, en su lugar, debe usar HTTPS. Una vez que se establece, el navegador usará HTTPS en lugar de HTTP para acceder al dominio sin un redireccionamiento durante un período definido en el encabezado.

Ejemplo de uso

Strict-Transport-Security: max-age=31536000
Cómo usar HSTS

Todos los sitios web que realicen la transición de HTTP a HTTPS deben responder con un encabezado Strict-Transport-Security cuando se reciba una solicitud con HTTP. 

Strict-Transport-Security: max-age=31536000

Navegadores compatibles

Browser Support

  • Chrome: 4.
  • Edge: 12.
  • Firefox: 4.
  • Safari: 7.

Source

Más información

Lecturas adicionales