Referência rápida sobre cabeçalhos de segurança

Saiba mais sobre cabeçalhos que podem manter seu site seguro e procurar rapidamente os detalhes mais importantes.

Eiji Kitamura
Artur Janc
Artur Janc
X GitHub
Maud Nalpas
Maud Nalpas
X GitHub

Este artigo lista os cabeçalhos de segurança mais importantes que podem ser usados para proteger seu site. Use esse recurso para entender os recursos de segurança baseados na Web e aprender a implementá-las em seu site e como referência para quando você precisar de um lembrete.

Cabeçalhos de segurança recomendados para sites que lidam com dados confidenciais do usuário:
Política de Segurança de Conteúdo (CSP)
Tipos confiáveis
Cabeçalhos de segurança recomendados para todos os sites:
X-Content-Type-Options
X-Frame-Options
Política de recursos entre origens (CORP)
Política de abertura de origem cruzada (COOP, na sigla em inglês)
Segurança de transporte restrito HTTP (HSTS, na sigla em inglês)
Cabeçalhos de segurança para sites com recursos avançados:
Compartilhamento de recursos entre origens (CORS)
Política de incorporador de origem cruzada (COEP, na sigla em inglês)
Ameaças conhecidas na Web
Antes de se aprofundar nos cabeçalhos de segurança, saiba mais sobre ameaças conhecidas na Web e por que usar esses cabeçalhos de segurança.

Antes de se aprofundar nos cabeçalhos de segurança, saiba mais sobre ameaças conhecidas na Web e por que usar esses cabeçalhos de segurança.

Proteja seu site contra vulnerabilidades de injeção

As vulnerabilidades de injeção surgem quando dados não confiáveis são processados pelo aplicativo pode afetar seu comportamento e, normalmente, levar à execução de scripts controlados pelo invasor. A vulnerabilidade mais comum causada pela injeção bugs é entre sites scripting (XSS) em suas várias formas, incluindo refletidas XSS, XSS armazenado, Com base em DOM XSS e outras variantes.

Uma vulnerabilidade XSS geralmente pode dar a um invasor acesso completo aos dados do usuário processados pelo aplicativo e qualquer outra informação hospedada no mesmo serviço origem.

As defesas tradicionais contra injeções incluem o uso consistente de escape automático. Sistemas de modelo HTML, evitando o uso de perigosos sistemas JavaScript APIs e o processamento adequado dos dados do usuário hospedando uploads de arquivos em um domínio separado e a limpeza do HTML controlado pelo usuário.

  • Usar a Política de Segurança de Conteúdo (CSP) para controlar quais scripts podem ser executada pelo aplicativo para reduzir o risco de injeções.
  • Use Tipos confiáveis para aplicar a sanitização dos dados transmitidos para ambientes APIs JavaScript do Google.
  • Use X-Content-Type-Options para impedir que o navegador interpretar incorretamente os tipos MIME dos recursos do site, o que pode levar a a execução do script.

Isolar seu site de outros sites

A abertura da Web permite que os sites interajam entre si de maneiras que podem violar as expectativas de segurança de um aplicativo. Isso inclui fazer solicitações autenticadas ou incorporar dados de outro aplicativo no do invasor, permitindo que ele modifique ou leia os dados do aplicativo.

Vulnerabilidades comuns que minam o isolamento da Web incluem clickjacking, entre sites request forgery (CSRF), cross-site inclusão de scripts (XSSI) e diversos vazamentos entre sites.

Web pós-espectro Desenvolvimento é uma ótima leitura se você tiver interesse neles.

Crie um site eficiente com segurança

Spectre: coloca todos os dados carregados no mesmo grupo de contexto de navegação, possivelmente legível apesar da política de mesma origem. Os navegadores restringem recursos que podem explorar a vulnerabilidade por trás de um ambiente especial chamado "isolamento de origem cruzada". Com o isolamento de origem cruzada, é possível use recursos avançados, como SharedArrayBuffer.

Criptografe tráfego para seu site

Os problemas de criptografia aparecem quando um aplicativo não criptografa totalmente os dados permitindo que invasores espelham informações sobre as interações dos usuários com o aplicativo.

A criptografia insuficiente pode ocorrer nestes casos: não usar HTTPS, conteúdo misto, configurando cookies sem a Secure atributo (ou __Secure prefixo), ou validação lax do CORS lógica.

Política de Segurança de Conteúdo (CSP)

Scripting em vários locais (XSS) é um ataque em que uma vulnerabilidade em um site permite que um script malicioso seja injetado e executada.

O Content-Security-Policy fornece uma camada adicional para mitigar ataques XSS: restringir quais scripts podem ser executados pela página.

É recomendável ativar a CSP restrita usando uma das seguintes abordagens:

  • Se você renderizar as páginas HTML no servidor, use uma CSP rigorosa com base em valor de uso único.
  • Se o seu HTML precisar ser veiculado estaticamente ou em cache, por exemplo, se for um aplicativo de página única, use uma CSP rigorosa baseada em hash.

Exemplo de uso: uma CSP com base em valor de uso único

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

1. Usar uma CSP rigorosa com base no valor de uso único {: #nonce-based-csp}

Se você renderizar as páginas HTML no servidor, use uma CSP rigorosa com base em valor de uso único.

Gere um novo valor de uso único do script para cada solicitação do lado do servidor e defina o seguinte cabeçalho:

arquivo de configuração do servidor

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

Em HTML, para carregar os scripts, defina o atributo nonce de todos <script> tags na mesma string {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>

O Google Fotos é uma boa CSP rigorosa com base em valor de uso único. exemplo. Use o DevTools para conferir como ele é usado.

2. Usar uma CSP rigorosa baseada em hash {: #hash-based-csp}

Se seu HTML precisar ser veiculado estaticamente ou em cache, por exemplo, se você criar um aplicativo de página única, use uma CSP rigorosa baseada em hash.

arquivo de configuração do servidor

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

Em HTML, você precisa inserir seus scripts in-line para aplicar uma regra política, já que a maioria dos navegadores não oferece suporte a hash scripts.

index.html

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

Para carregar scripts externos, leia "Carregar scripts de origem dinamicamente". abaixo Seção Opção B: cabeçalho de resposta da CSP com base em hash.

O CSP Evaluator é uma boa ferramenta para avaliar seu CSP, mas ao mesmo tempo que um bom exemplo de CSP estrito com base no valor de uso único. Use o DevTools para conferir como ele é usado.

Navegadores compatíveis

Outras observações sobre a CSP

  • frame-ancestors protege seu site contra clickjacking, um risco que surge se você permitir sites não confiáveis para incorporar os seus. Se preferir uma solução mais simples, use X-Frame-Options para bloquear o carregamento, mas frame-ancestors fornece uma configuração avançada para permitir apenas origens específicas como incorporadores.
  • Talvez você tenha usado uma CSP para garantir que todos os recursos do seu site sejam carregados por HTTPS. Isso tem se tornarem menos relevantes: hoje, a maioria dos navegadores bloqueia conteúdo misto.
  • Também é possível definir uma CSP no modo somente relatórios .
  • Se não for possível definir um CSP como cabeçalho do lado do servidor, configure-o como um meta tag. Não é possível usar o modo somente relatórios para metatags (embora isso pode mudar).

Saiba mais

Tipos confiáveis

Com base em DOM O XSS é uma em que dados maliciosos são passados para um coletor compatível com código dinâmico como eval() ou .innerHTML.

Os Tipos confiáveis oferecem as ferramentas necessárias para escrever, revisar e manter aplicativos sem XSS do DOM. Eles podem ser ativados via CSP e fazer O código JavaScript é seguro por padrão, limitando as APIs da Web perigosas a aceitar apenas um objeto especial, um tipo confiável.

Para criar esses objetos, é possível definir políticas de segurança que garantam que as regras de segurança (como escape ou sanitização) sejam aplicadas de maneira consistente. antes que os dados sejam gravados no DOM. Essas políticas são os únicos lugares no código que poderia introduzir o DOM XSS.

Exemplos 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;
Como usar Tipos confiáveis

  1. Aplicar tipos confiáveis para coletores do DOM perigosos Cabeçalho da CSP e dos tipos confiáveis: 

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

    Atualmente, 'script' é o único valor aceitável para require-trusted-types-for.

    É possível combinar Tipos confiáveis com outras diretivas da CSP:

Mesclagem de um CSP baseado em valor de uso único acima com Tipos confiáveis: 

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>Observação:</b> É possível limitar os nomes de políticas de Tipos confiáveis permitidos definindo mais <code>tipos confiáveis</code> (por exemplo, <code>trusted-types myPolicy</code>). No entanto, isso não é um requisito.  </aside>


    
  
  1. 
    
    Definir uma 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. 
    
    Aplicar a política
    
    
    Use a política ao gravar dados no 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;

    
    
    Com o require-trusted-types-for 'script', usar um tipo confiável é uma
      requisito fundamental. O uso de uma API do DOM perigosa com uma string resultará em uma
      erro.
    
  
    3. 



Navegadores compatíveis



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


Saiba mais

X-Content-Type-Options

Quando um documento HTML malicioso é disponibilizado a partir de seu domínio (por exemplo, se um imagem enviada para um serviço de fotos contém marcação HTML válida), alguns navegadores vai tratá-lo como um documento ativo e permitir que ele execute scripts na do aplicativo, levando a um scripting em vários sites bug.

X-Content-Type-Options: nosniff impede isso ao instruir o navegador que o tipo MIME definido no o cabeçalho Content-Type de uma determinada resposta está correto. Este cabeçalho é recomendado para todos os seus recursos.

Exemplo de uso

X-Content-Type-Options: nosniff
Como usar X-Content-Type-Options

A opção X-Content-Type-Options: nosniff é recomendada para todos os recursos disponibilizados em seu servidor, além do cabeçalho Content-Type correto.

X-Content-Type-Options: nosniff

Exemplos de cabeçalhos enviados com um documento HTML

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

Navegadores compatíveis

Compatibilidade com navegadores

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

Origem

Saiba mais

X-Frame-Options

Se um site malicioso conseguir incorporar seu site como um iframe, isso poderá permitir os invasores invoquem ações não intencionais do usuário com clickjacking. Além disso, em alguns casos Tipo Spectre ataques dão sites maliciosos tenham a chance de aprender sobre o conteúdo de um documento incorporado.

X-Frame-Options indica se um navegador tem permissão para renderizar. uma página em um <frame>, <iframe>, <embed> ou <object>. Todos os documentos é recomendável enviar esse cabeçalho para indicar se eles permitem ser incorporados por outros documentos.

Exemplo de uso

X-Frame-Options: DENY
Como usar o X-Frame-Options

Todos os documentos que não foram projetados para serem incorporados precisam usar o cabeçalho X-Frame-Options.

Tente como as configurações a seguir afetam o carregamento de um iframe neste demonstração. Mudar o X-Frame-Options e clique no botão Atualizar o iframe.

Protege seu site contra a incorporação de outros sites.

Negar serem incorporados por outros documentos.

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

Protege seu site contra a incorporação por sites de origem cruzada.

Permitir a incorporação apenas por documentos de mesma origem.

X-Frame-Options: SAMEORIGIN

Navegadores compatíveis

Compatibilidade com navegadores

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

Origem

Saiba mais

Política de recursos entre origens (CORP, na sigla em inglês)

Um invasor pode incorporar recursos de outra origem, por exemplo, do seu site, para aprender informações sobre elas, explorando a plataforma entre sites vazamentos de dados.

Cross-Origin-Resource-Policy reduz esse risco indicando o conjunto de os sites em que podem ser carregados. O cabeçalho usa um destes três valores: same-origin, same-site e cross-origin. Todos os recursos estão recomendado enviar esse cabeçalho para indicar se eles permitem o carregamento e outros sites.

Exemplo de uso

Cross-Origin-Resource-Policy: same-origin
Como usar o CORP

É recomendável que todos os recursos sejam disponibilizados com um dos seguintes três cabeçalhos.

Tente como as configurações a seguir afetam o carregamento de recursos em um ambiente Cross-Origin-Embedder-Policy: require-corp neste demonstração. Altere o Cross-Origin-Resource-Policy e clique no botão Atualizar iframe ou Atualizar a imagem para conferir o efeito.

Permitir que os recursos sejam carregados cross-origin

É recomendável que os serviços como CDN apliquem cross-origin aos recursos (pois são normalmente carregados por páginas de origem cruzada), a menos que já tenham sido veiculados pelo CORS, que tem um efeito semelhante.

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

Limitar os recursos a serem carregados do same-origin

same-origin precisa ser aplicado somente aos recursos que precisam ser carregados por páginas de mesma origem. Isso deve ser aplicado a recursos que incluem dados informações sobre o usuário ou respostas de uma API que deveria ser chamada apenas da mesma origem.

Lembre-se de que os recursos com esse cabeçalho ainda podem ser carregados diretamente, para exemplo navegando até o URL em uma nova janela do navegador. Recurso de origem cruzada A política só protege o recurso contra a incorporação por outros sites.

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

Limitar os recursos a serem carregados do same-site

Recomenda-se que a same-site seja aplicada a recursos semelhantes ao exemplo acima. mas devem ser carregados por outros subdomínios do seu site.

Política de recursos entre origens: mesmo site 
Cross-Origin-Resource-Policy: same-site

Navegadores compatíveis

Compatibilidade com navegadores

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

Origem

Saiba mais

Política de abertura de origem cruzada (COOP, na sigla em inglês)

O site de um invasor pode abrir outro site em uma janela pop-up para aprender mais informações sobre ele explorando vários sites vazamentos de dados. Em alguns casos, isso também pode permitir que exploração de ataques de canal lateral com base no Spectre:

O cabeçalho Cross-Origin-Opener-Policy permite isolar um documento a partir de janelas de origem cruzada abertas por window.open() ou um link com target="_blank" sem rel="noopener". Como resultado, qualquer abertura de origem cruzada do documento não terão referência a ele e não poderão interagir a ele.

Exemplo de uso

Cross-Origin-Opener-Policy: same-origin-allow-popups
Como usar a COOP

Tente como as configurações a seguir afetam a comunicação com um janela pop-up de origem cruzada nesta demonstração. Alterar o menu suspenso Cross-Origin-Opener-Policy para o documento e na janela pop-up, clique no botão Abrir um pop-up e depois em Enviar uma postMessage para ver se a mensagem é realmente entregue.

Isolar um documento de janelas de origem cruzada

Definir same-origin isola o documento da origem cruzada janelas de documentos.

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

Isolar um documento de janelas de origem cruzada, mas permitir pop-ups

A configuração same-origin-allow-popups permite que um documento retenha uma referência a as janelas pop-up, a menos que definam COOP com same-origin ou same-origin-allow-popups: Isso significa que same-origin-allow-popups ainda pode proteger o documento de ser referenciado quando aberto como uma janela pop-up, mas permitem que ele se comunique com seus próprios pop-ups.

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

Permitir que um documento seja referenciado por janelas de origem cruzada

unsafe-none é o valor padrão, mas é possível indicar explicitamente que esse documento possa ser aberto por uma janela de origem cruzada e manter o acesso mútuo.

Cross-Origin-Opener-Policy: não seguro . 
Cross-Origin-Opener-Policy: unsafe-none

Padrões de relatório incompatíveis com a COOP

Você poderá receber relatórios quando a COOP impedir interações entre janelas com o API Reporting.

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

A COOP também é compatível com o modo somente relatório. Assim, você pode receber relatórios sem para bloquear a comunicação entre documentos de origem cruzada.

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

Navegadores compatíveis

Compatibilidade com navegadores

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

Origem

Saiba mais

Compartilhamento de recursos entre origens (CORS, na sigla em inglês)

Ao contrário de outros itens neste artigo, o Compartilhamento de recursos entre origens (CORS) não é um cabeçalho, mas um mecanismo de navegador que solicita e permite acesso a recursos entre origens.

Por padrão, os navegadores aplicam a política de mesma origem aos impedir que uma página da Web acesse recursos de origem cruzada. Por exemplo, quando um imagem de origem cruzada é carregada, mesmo que seja exibida na página da Web visualmente, o JavaScript na página não tem acesso aos dados da imagem. O provedor de recursos pode flexibilizar as restrições e permitir que outros sites leiam o recurso ativando o CORS.

Exemplo de uso

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
Como usar o CORS

Antes de ver como configurar o CORS, é útil entender as a diferença entre os tipos de solicitações. Dependendo dos detalhes da solicitação, será classificada como solicitação simples ou solicitação simulada.

Critérios para uma solicitação simples:

  • O método é GET, HEAD ou POST.
  • Os cabeçalhos personalizados incluem apenas Accept, Accept-Language, Content-Language e Content-Type.
  • O valor da coluna Content-Type é application/x-www-form-urlencoded. multipart/form-data ou text/plain.

Todo o restante é classificado como uma solicitação simulada. Para mais detalhes, confira Compartilhamento de recursos entre origens (CORS) - HTTP | MDN.

Solicitação simples

Quando uma solicitação atende aos critérios de solicitação simples, o navegador envia uma solicitação entre origens com um cabeçalho Origin que indica a solicitação origem.

Exemplo de cabeçalho de solicitação

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

Exemplo de cabeçalho de resposta

Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin: https://example.com indica que o https://example.com pode acessar o conteúdo da resposta. Recursos pretendidos para que possa ser lido por qualquer site, defina esse cabeçalho como *. Nesse caso, navegador só exigirá que a solicitação seja feita sem credenciais.
  • Access-Control-Allow-Credentials: true indica que as solicitações que transportam credenciais (cookies) têm permissão para carregar o recurso. Caso contrário, solicitações autenticadas serão rejeitadas mesmo se a origem solicitante for presente no cabeçalho Access-Control-Allow-Origin.

Tente como a solicitação simples afeta o carregamento de recursos em uma ambiente Cross-Origin-Embedder-Policy: require-corp neste demonstração. Clique no botão Compartilhamento de recursos entre origens e clique em Atualizar a imagem. para conferir o efeito.

Solicitações simuladas

Uma solicitação de simulação é precedida por uma solicitação OPTIONS para verificar se o solicitação seguinte pode ser enviada.

Exemplo de cabeçalho de solicitação

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 a solicitação a seguir seja feita com o método POST.
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type permite que solicitante defina os cabeçalhos HTTP X-PINGOTHER e Content-Type na solicitação subsequente.

Exemplos de cabeçalhos de resposta

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 as As solicitações podem ser feitas com os métodos POST, GET e OPTIONS.
  • Access-Control-Allow-Headers: X-PINGOTHER, Content-Type indica subsequentes podem incluir os cabeçalhos X-PINGOTHER e Content-Type.
  • Access-Control-Max-Age: 86400 indica que o resultado da simulação pode ser armazenada em cache por 86.400 segundos.

Navegadores compatíveis

Compatibilidade com navegadores

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

Origem

Saiba mais

Política de incorporador de origem cruzada (COEP, na sigla em inglês)

Para reduzir a capacidade baseada em Spectre ataques para roubar recursos de origem cruzada, atributos como SharedArrayBuffer ou performance.measureUserAgentSpecificMemory() estão desativados por padrão.

Cross-Origin-Embedder-Policy: require-corp impede que documentos e workers carregando recursos de origem cruzada, como imagens, scripts, folhas de estilo, iframes e outros, a menos que esses recursos optem explicitamente pelo carregamento via CORS ou cabeçalhos do CORP. O COEP pode ser combinado com aCross-Origin-Opener-Policy para ativar o isolamento de origem cruzada de um documento.

Use Cross-Origin-Embedder-Policy: require-corp quando quiser ativar isolamento de origem cruzada para seu documento.

Exemplo de uso

Cross-Origin-Embedder-Policy: require-corp
Como usar o COEP

Exemplos de uso

O COEP usa um único valor de require-corp. Ao enviar esse cabeçalho, você pode instrua o navegador a bloquear o carregamento de recursos que não são ativados pelo CORS ou CORP.

Como o COEP funciona

Tente como as configurações a seguir afetam o carregamento de recursos neste demonstração. Altere o menu suspenso Cross-Origin-Embedder-Policy, a Menu suspenso Cross-Origin-Resource-Policy, a caixa de seleção Somente relatório etc. para conferir como elas afetam o carregamento de recursos. Além disso, abra o endpoint de relatórios demo para ver se os recursos bloqueados relatadas.

Ativar isolamento de origem cruzada

Ative o isolamento de origem cruzada enviando Cross-Origin-Embedder-Policy: require-corp junto com Cross-Origin-Opener-Policy: same-origin. 

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

Informar recursos incompatíveis com o COEP

É possível receber relatórios de recursos bloqueados causados pelo COEP com a guia "Relatórios" API.

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

O COEP também é compatível com o modo somente relatório. Assim, você pode receber relatórios como bloquear o carregamento de recursos.

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

Navegadores compatíveis

Compatibilidade com navegadores

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

Origem

Saiba mais

Segurança de transporte restrito HTTP (HSTS, na sigla em inglês)

A comunicação por uma conexão HTTP simples não é criptografada, tornando dados transferidos acessíveis a intrusos no nível da rede.

O cabeçalho Strict-Transport-Security informa ao navegador que ele nunca deve carregar o site usando HTTP. Em vez disso, use HTTPS. Depois de definido, o navegador usará HTTPS em vez de HTTP para acessar o domínio sem um redirecionamento por um período definido no cabeçalho.

Exemplo de uso

Strict-Transport-Security: max-age=31536000
Como usar o HSTS

Todos os sites que fazem a transição de HTTP para HTTPS devem responder com uma Cabeçalho Strict-Transport-Security quando uma solicitação com HTTP é recebida. 

Strict-Transport-Security: max-age=31536000

Navegadores compatíveis

Compatibilidade com navegadores

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

Origem

Saiba mais

Leitura adicional