Obtén más información sobre los encabezados que pueden mantener tu sitio seguro y consulta rápidamente los detalles más importantes.
En este artículo, se mencionan 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 para cuando necesites un recordatorio.
- Encabezados de seguridad recomendados para sitios web que manejan datos sensibles de los usuarios:
- Política de Seguridad del Contenido (CSP)
- Tipos de confianza
- Encabezados de seguridad recomendados para todos los sitios web:
- X-Content-Type-Options
- X-Frame-Options
- Política de recursos multiorigen (CORP)
- Política de abridor multiorigen (COOP)
- HTTP con Seguridad de Transporte Estricta (HSTS)
- Encabezados de seguridad para sitios web con funciones avanzadas:
- Uso compartido de recursos multiorigen (CORS)
- Política de incorporaciones de origen cruzado (COEP)
Antes de sumergirte en los encabezados de seguridad, obtén información sobre las amenazas conocidas en la Web y por qué deberías usarlos.
Protege tu sitio de las vulnerabilidades de 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, dar lugar a 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, como XSS reflejado, XSS almacenado, XSS basado en DOM y otras variantes.
Por lo general, una vulnerabilidad XSS puede darle 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, la prevención del uso de APIs peligrosas de JavaScript y el procesamiento adecuado de los datos del usuario mediante el alojamiento de cargas de archivos en un dominio independiente y la limpieza de 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 APIs de JavaScript peligrosas.
- Usa X-Content-Type-Options para evitar que el navegador malinterprete los tipos de MIME de los recursos de tu sitio web, lo que puede provocar la ejecución de secuencias de comandos.
Cómo aislar tu sitio de otros sitios web
La apertura de la Web permite que los sitios web interactúen entre sí de maneras que pueden infringir 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 datos de la aplicación.
Las vulnerabilidades comunes que socaven el aislamiento web incluyen la captura de clic, la falsificación de solicitudes entre sitios (CSRF), la inclusión de secuencias de comandos entre sitios (XSSI) y varias filtraciones entre sitios.
- Usa X-Frame-Options para evitar que un sitio web malicioso incorpore tus documentos.
- Usa la Política de recursos multiorigen (CORP) para evitar que un sitio web de origen cruzado incluya los recursos de tu sitio web.
- Usa la Política de abridor multiorigen (COOP) para proteger las ventanas de tu sitio web de las interacciones que realizan sitios web maliciosos.
- Usa el uso compartido de recursos entre dominios (CORS) para controlar el acceso a los recursos de tu sitio web desde documentos de distintos orígenes.
Post-Spectre Web Development es una excelente lectura si te interesan estos encabezados.
Crea un sitio web potente de forma segura
Spectre coloca los datos cargados en el mismo grupo de contexto de navegación potencialmente legibles a pesar de la política de mismo origen. Los navegadores restringen funciones
que pueden explotar 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
.
- Usa la Política de incorporaciones de origen cruzado (COEP) junto con COOP para habilitar el aislamiento de origen cruzado.
Encripta el tráfico hacia 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 espías obtengan información sobre las interacciones del usuario con la aplicación.
La encriptación insuficiente puede surgir en los siguientes casos: no usar HTTPS, contenido mixto, configurar cookies sin el atributo Secure
(o el prefijo __Secure
) o la lógica de validación laxa de CORS.
- Usa HTTP con Seguridad de Transporte Estricta (HSTS) para entregar tu contenido de forma sistemática a través de HTTPS.
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 inserte y ejecute una secuencia de comandos maliciosa.
Content-Security-Policy
proporciona una capa adicional para mitigar los ataques de XSS, ya que restringe las secuencias de comandos que la página puede ejecutar.
Se recomienda que habilites una CSP estricta mediante uno de los siguientes enfoques:
- Si procesas tus páginas HTML en el servidor, usa una CSP estricta basada en nonce.
- Si tu c��digo HTML debe entregarse de forma estática o almacenar en caché, por ejemplo, si es una aplicación de una sola página, usa una CSP estricta basada en hash.
Ejemplo de uso: una CSP basada en nonce
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
Usos recomendados
1. Usa una CSP estricta basada en nonce {: #nonce-based-csp}
Si procesas 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, configura 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 CSP estricta basado en nonce. Usa las Herramientas para desarrolladores para ver cómo se usa.
2. Usa una CSP estricta basada en hash {: #hash-based-csp}
Si tu código HTML debe entregarse de forma estática o almacenar en caché, por ejemplo, si estás compilando 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 intercalar las secuencias de comandos para aplicar una política basada en hash, ya que la mayoría de los navegadores no admiten la codificación 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 la CSP basado en hash.
CSP Evaluator es una buena herramienta para evaluar tu CSP, pero, al mismo tiempo, es un buen ejemplo de CSP estricta basado en nonce. Usa las Herramientas para desarrolladores para ver cómo se usa.
Navegadores admitidos
Otros aspectos que debes tener en cuenta sobre la CSP
- La directiva
frame-ancestors
protege tu sitio contra el clickjacking, un riesgo que surge si permites que sitios que no son de confianza incorporen el tuyo. Si prefieres una solución más simple, puedes usarX-Frame-Options
para bloquear la carga, peroframe-ancestors
te brinda una configuración avanzada con el objetivo de permitir solo orígenes específicos como incorporaciones. - 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 es menos relevante: hoy en día, la mayoría de los navegadores bloquean el contenido mixto.
- También puedes establecer una CSP en el modo de solo informes.
- Si no puedes establecer una CSP como encabezado del servidor, también puedes establecerla como metaetiqueta. Ten en cuenta que no puedes usar el modo solo informes para las metaetiquetas (aunque esto puede cambiar).
Más información
Tipos de confianza
La XSS basado en 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 las aplicaciones libres de DOM XSS. Se pueden habilitar a través de CSP y hacer que el código JavaScript sea seguro de forma predeterminada al limitar las APIs web peligrosas para que solo acepten un objeto especial, es decir, un tipo de confianza.
Para crear estos objetos, puedes definir políticas de seguridad, en las que puedes asegurarte de que se apliquen reglas de seguridad (como el escape o la limpieza) de manera coherente antes de que los datos se escriban en el DOM. Estas políticas son los únicos lugares en el código que podrían introducir potencialmente DOM XSS.
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, '<').replace(/>/g, '>');
}
});
}
// Assignment of raw strings is blocked by Trusted Types.
el.innerHTML = 'some string'; // This throws an exception.
// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src=x onerror=alert(1)>');
el.innerHTML = escaped; // '&lt;img src=x onerror=alert(1)&gt;'
Usos recomendados
-
Aplica Trusted Types para receptores de DOM peligrosos Encabezado de la CSP y Trusted Types:
Content-Security-Policy: require-trusted-types-for 'script'
En este momento,
'script'
es el único valor aceptable para la directivarequire-trusted-types-for
.Puedes combinar Trusted Types con otras directivas de CSP:
Combina una CSP basada en nonce anterior con Trusted Types:
Content-Security-Policy:
script-src 'nonce-{RANDOM1}' 'strict-dynamic' https: 'unsafe-inline';
object-src 'none';
base-uri 'none';
require-trusted-types-for 'script';
<aside class="note"><b>Nota: </b> Puedes limitar los nombres de políticas de Trusted Types permitidos si estableces una directiva <code>trusted-types</code> adicional (por ejemplo, <code>trusted-types myPolicy</code>). Sin embargo, esto no es un requisito. </aside>
-
Define 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, '>');
}
});
}
-
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 = 'some string'; // This throws an exception.</p>
<p>// Assignment of Trusted Types is accepted safely.
const escaped = policy.createHTML('<img src="x" onerror="alert(1)">');
el.innerHTML = escaped; // '<img src=x onerror=alert(1)>'
Con require-trusted-types-for 'script'
, el uso de un tipo de confianza es un requisito. El uso de una API peligrosa de DOM con una cadena generará un
error.
Navegadores admitidos
Más información
- Evita las vulnerabilidades de secuencias de comandos entre sitios basadas en DOM con Trusted Types
- CSP: required-trusted-types-for - HTTP | MDN
- CSP: tipos de confianza - HTTP | MDN
- Demostración de Trusted Types: Abre el Inspector de Herramientas para desarrolladores y observa lo que sucede.
X-Content-Type-Options
Cuando se entrega un documento HTML malicioso desde tu dominio (por ejemplo, si una imagen subida a un servicio de fotos contiene lenguaje de marcado HTML válido), algunos navegadores lo tratarán como un documento activo y le permitirán ejecutar secuencias de comandos en el contexto de la aplicación, lo que genera un error de secuencia 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 dada es correcto. Se recomienda este encabezado para todos los recursos.
Ejemplo de uso
X-Content-Type-Options: nosniff
Cómo usar X-Content-Type-Options
Usos recomendados
Se recomienda X-Content-Type-Options: nosniff
para todos los recursos que se entregan desde tu servidor junto con el encabezado Content-Type
correcto.
Ejemplos de encabezados enviados con un documento HTML
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
Navegadores admitidos
Más información
Opciones de X-Frame
Si un sitio web malicioso puede incorporar tu sitio como un iframe, es posible que los atacantes invoquen acciones no deseadas por parte del usuario con un clickjacking. Además, en algunos casos, los ataques de tipo espectro brindan a los sitios web maliciosos la oportunidad de aprender 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 la incorporación en otros documentos.
Ejemplo de uso
X-Frame-Options: DENY
Cómo usar X-Frame-Options
Usos recomendados
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 Volver a cargar el iframe.
Protegen tu sitio web de que otros sitios web no puedan incorporarlo.
Negar que ningún otro documento pueda incorporarlo
X-Frame-Options: DENY
Protege tu sitio web contra los sitios web de origen cruzado.
Permitir que solo los documentos del mismo origen puedan incorporar
X-Frame-Options: SAMEORIGIN
Navegadores admitidos
Más información
Política de recursos entre dominios (CORP)
Un atacante puede incorporar recursos de otro origen, por ejemplo, desde tu sitio, para obtener información sobre ellos aprovechando las filtraciones entre sitios basadas en la Web.
Cross-Origin-Resource-Policy
mitiga este riesgo indicando el conjunto de sitios web que pueden utilizar para realizar la carga. 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 lo carguen.
Ejemplo de uso
Cross-Origin-Resource-Policy: same-origin
Cómo usar CORP
Usos recomendados
Se recomienda que todos los recursos se entreguen con uno de los siguientes tres encabezados.
Puedes probar cómo los siguientes parámetros de configuración afectan la carga de recursos en un
entorno 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 Volver a cargar el iframe o Volver a cargar la imagen para ver el efecto.
Permitir que se carguen los 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 entreguen a través de CORS, lo que tiene un efecto similar.
Cross-Origin-Resource-Policy: cross-origin
Limita los recursos que se cargarán desde same-origin
same-origin
debe aplicarse a los recursos diseñados para que se carguen solo en páginas del mismo origen. Debes aplicar esto a los recursos que incluyan información sensible sobre el usuario o a las respuestas de una API cuya llamada solo se realizará desde el mismo origen.
Ten en cuenta que los recursos con este encabezado aún se pueden cargar directamente, por
ejemplo, si navegas a la URL en una ventana nueva del navegador. La Política de recursos entre dominios
solo protege el recurso para que no sea incorporado en otros sitios web.
Cross-Origin-Resource-Policy: same-origin
Limita los recursos que se cargarán desde same-site
Se recomienda aplicar same-site
a recursos similares a los anteriores, pero que están diseñados para que los carguen otros subdominios de tu sitio.
Cross-Origin-Resource-Policy: same-site
Navegadores admitidos
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 al respecto mediante la explotación de 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 mediante window.open()
o un vínculo con target="_blank"
sin rel="noopener"
. Como resultado, cualquier abridor de origen cruzado
del documento no tendrá referencia a él y no podrá interactuar
con él.
Ejemplo de uso
Cross-Origin-Opener-Policy: same-origin-allow-popups
Cómo usar COOP
Usos recomendados
En esta demostración, puedes probar cómo los siguientes parámetros de configuración afectan la comunicación con una ventana emergente de origen cruzado.
Cambia el menú desplegable Cross-Origin-Opener-Policy del documento
como en la ventana emergente, haz clic en el botón Abrir una ventana emergente y, luego, en Enviar
postMessage para ver si el mensaje se entregó realmente.
Aísla un documento de ventanas de origen cruzado
La configuración de same-origin
hace que el documento se aísle de las ventanas de documentos de origen cruzado.
Cross-Origin-Opener-Policy: same-origin
Aísla un documento de las ventanas de origen cruzado, pero permite las ventanas emergentes
Si se configura same-origin-allow-popups
, un documento puede retener una referencia a sus ventanas emergentes, a menos que configuren 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 abre como una ventana emergente, pero permite que se comunique con sus propias ventanas emergentes.
Cross-Origin-Opener-Policy: same-origin-allow-popups
Permitir que las ventanas de origen cruzado hagan referencia a un documento
unsafe-none
es el valor predeterminado, pero puedes indicar explícitamente que este
documento se puede abrir mediante una ventana de origen cruzado y conservar el acceso mutuo.
Cross-Origin-Opener-Policy: unsafe-none
Patrones de informes incompatibles con la COOP
Puedes recibir informes cuando la 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, por lo que puedes recibir informes sin
bloquear la comunicación entre documentos de origen cruzado.
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
Navegadores admitidos
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 del mismo origen para
evitar que una página web acceda a recursos de origen cruzado. Por ejemplo, cuando se carga una imagen de origen cruzado, aunque se muestre visualmente en la página web, el JavaScript de la página no tiene acceso a los datos de la imagen.
El proveedor de recursos puede disminuir la rigurosidad de las restricciones y permitir que otros sitios web lean el recurso mediante la habilitación del 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 el CORS, es útil comprender la distinción entre tipos de solicitud. Según los detalles de la solicitud, una solicitud se
clasificará como una solicitud simple o una solicitud con verificación previa.
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 con verificación previa. Para obtener más información, consulta Uso compartido de recursos multiorigen (CORS): HTTP | MDN.
Usos recomendados
Solicitud simple
Cuando una solicitud cumple con los criterios simples, 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 https://example.com
puede acceder al contenido de la respuesta. Los recursos que cualquier sitio puede leer pueden configurar este encabezado como *
, en cuyo caso el navegador solo requerirá que la solicitud se realice sin credenciales.
Access-Control-Allow-Credentials: true
indica que las solicitudes que llevan 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 una solicitud simple afecta la carga de recursos en un entorno Cross-Origin-Embedder-Policy: require-corp
en esta demostración. Haz clic en la casilla de verificación Uso compartido de recursos entre dominios y, luego, en el botón Volver a cargar la imagen para ver el efecto.
Solicitudes con verificación previa
A una solicitud con verificación previa se le antepone una solicitud OPTIONS
para verificar si se puede 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 realizar 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.
Ejemplos 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 con verificación previa se puede almacenar en caché durante 86,400 segundos.
Navegadores admitidos
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, funciones como SharedArrayBuffer
o performance.measureUserAgentSpecificMemory()
están inhabilitadas de forma predeterminada.
Cross-Origin-Embedder-Policy: require-corp
evita que los documentos y trabajadores carguen recursos de origen cruzado, como imágenes, secuencias de comandos, hojas de estilo, iframes, etc., a menos que estos recursos opten explícitamente por cargarse a través de encabezados CORS o CORP. COEP se puede combinar con Cross-Origin-Opener-Policy
para habilitar el aislamiento de origen cruzado de un documento.
Usa Cross-Origin-Embedder-Policy: require-corp
cuando quieras habilitar el
aislamiento de origen cruzado en tu documento.
Ejemplo de uso
Cross-Origin-Embedder-Policy: require-corp
Cómo usar COEP
Ejemplos de uso
El COEP toma un solo valor de require-corp
. Si envías este encabezado, puedes indicarle al navegador que bloquee los recursos de carga que no habiliten mediante CORS o CORP.
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 y 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.
Habilitar el aislamiento de origen cruzado
Para habilitar el aislamiento de origen cruzado, envía 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
Informar sobre recursos incompatibles con el COEP
Puedes recibir informes de recursos bloqueados causados por el COEP con la API
de Reporting.
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"
COEP también admite el modo de solo informes, por lo que puedes recibir informes sin bloquear los recursos de carga.
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"
Navegadores admitidos
Más información
HTTP con Seguridad de Transporte Estricta (HSTS)
La comunicación a través de una conexión HTTP simple no está encriptada, lo que hace que los datos transferidos sean accesibles para los espías a nivel de la red.
El encabezado Strict-Transport-Security
informa al navegador que nunca debe cargar el sitio con HTTP y usar HTTPS en su lugar. Una vez establecido, el navegador usará
HTTPS en lugar de HTTP para acceder al dominio sin redireccionamiento
durante el tiempo que se defina en el encabezado.
Ejemplo de uso
Strict-Transport-Security: max-age=31536000
Cómo usar HSTS
Usos recomendados
Todos los sitios web que realizan la transición de HTTP a HTTPS deben responder con un encabezado Strict-Transport-Security
cuando se recibe una solicitud con HTTP.
Strict-Transport-Security: max-age=31536000
Navegadores admitidos
Más información
Lecturas adicionales