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

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

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

Neste artigo, listamos os cabeçalhos de segurança mais importantes que podem ser usados para proteger seu site. Use-o para entender os recursos de segurança baseados na Web, saber como implementá-los no 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 entre origens (COOP, na sigla em inglês)
HTTP Strict Transport Security (HSTS)
Cabeçalhos de segurança para sites com recursos avançados:
Compartilhamento de recursos entre origens (CORS)
Política do incorporador entre origens (COEP)
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

Vulnerabilidades de injeção surgem quando dados não confiáveis processados pelo aplicativo podem afetar o comportamento dele e, geralmente, levar à execução de scripts controlados por invasores. A vulnerabilidade mais comum causada por bugs de injeção é o scripting em vários locais (XSS) em várias formas, incluindo XSS refletido, XSS armazenado, XSS baseado em DOM e outras variantes.

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

As defesas tradicionais contra injeções incluem o uso consistente de sistemas de modelos HTML com escape automático, evitando o uso de APIs JavaScript perigosas e processando adequadamente os dados do usuário, hospedando os uploads de arquivos em um domínio separado e limpando o HTML controlado pelo usuário.

  • Use a Política de Segurança de Conteúdo (CSP) para controlar quais scripts podem ser executados pelo aplicativo e reduzir o risco de injeções.
  • Use Tipos confiáveis para aplicar a limpeza de dados transmitidos para APIs JavaScript perigosas.
  • Use X-Content-Type-Options para evitar que o navegador interprete incorretamente os tipos MIME dos recursos do seu site, o que pode levar à 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 documento do invasor, permitindo que o invasor modifique ou leia os dados do app.

As vulnerabilidades comuns que prejudicam o isolamento da Web incluem cliques, falsificação de solicitações entre sites (CSRF, na sigla em inglês), inclusão de scripts entre sites (XSSI, na sigla em inglês) e vários vazamentos entre sites.

O Desenvolvimento Web após o Spectre é uma ótima leitura se você tiver interesse nesses cabeçalhos.

Crie um site eficiente com segurança

O 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 usar recursos avançados, como SharedArrayBuffer.

Criptografar o tráfego para seu site

Os problemas de criptografia aparecem quando um aplicativo não criptografa totalmente os dados em trânsito, permitindo que os invasores aprendam sobre as interações do usuário com o aplicativo.

A criptografia insuficiente pode surgir nos seguintes casos: não usar HTTPS, conteúdo misto, definir cookies sem o atributo Secure (ou prefixo __Secure) ou lógica de validação do CORS lenta.

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

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

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

Recomendamos que você ative a CSP rigorosa usando uma destas abordagens:

  • Se você renderizar suas páginas HTML no servidor, use uma CSP rigorosa com base no valor de uso único.
  • Caso o HTML precise ser veiculado estaticamente ou em cache, por exemplo, no caso de um aplicativo de página única, use uma CSP estrita baseada em hash.

Exemplo de uso: uma CSP baseada 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. Use uma CSP rigorosa com base no valor de uso único {: #nonce-based-csp}

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

Gere um novo valor de uso único do script para cada solicitação no 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 todas as tags <script> para a 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 é um bom exemplo de CSP com base em valor de uso único. Use o DevTools para saber como ele é usado.

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

Caso seu HTML precise ser veiculado estaticamente ou em cache, por exemplo, se você estiver criando um aplicativo de página única, use uma CSP estrita 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ê precisará alinhar os scripts para aplicar uma política baseada em hash, porque a maioria dos navegadores não é compatível com scripts externos de hash.

index.html

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

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

O Avaliador de CSP é uma boa ferramenta para avaliar sua CSP, mas, ao mesmo tempo, um bom exemplo rigoroso de CSP com base no valor de uso único. Use o DevTools para saber como ele é usado.

Navegadores compatíveis

Outras observações sobre a CSP

  • A diretiva frame-ancestors protege seu site contra clickjacking, um risco que surge se você permitir que sites não confiáveis incorporem o seu. Se você preferir uma solução mais simples, poderá usar X-Frame-Options para bloquear o carregamento, mas o frame-ancestors oferece 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 se tornou menos relevante: hoje em dia, a maioria dos navegadores bloqueia conteúdo misto.
  • Você também pode definir uma CSP no modo somente relatório.
  • Se não for possível definir uma CSP como um cabeçalho do lado do servidor, você também poderá fazer isso como uma metatag. Não é possível usar o modo somente relatório para metatags, embora isso possa mudar.

Saiba mais

Tipos confiáveis

XSS baseado em DOM é um ataque em que dados maliciosos são transmitidos para um coletor compatível com a execução de código dinâmico, como eval() ou .innerHTML.

Os tipos confiáveis oferecem as ferramentas para escrever, analisar a segurança e manter aplicativos livres de XSS do DOM. Elas podem ser ativadas usando a CSP e tornar o código JavaScript seguro por padrão, limitando APIs da Web perigosas para aceitar apenas um objeto especial, um tipo confiável.

Para criar esses objetos, defina políticas de segurança em que é possível garantir que as regras de segurança (como escape ou limpeza) sejam aplicadas de maneira consistente antes que os dados sejam gravados no DOM. Essas políticas são os únicos locais no código que podem introduzir o XSS do DOM.

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 os Tipos confiáveis

  1. Aplique tipos confiáveis para coletores DOM perigosos cabeçalho de CSP e Tipos confiáveis: 

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

    No momento, 'script' é o único valor aceitável para a diretiva require-trusted-types-for.

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

Combinar uma CSP baseada 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> você pode limitar os nomes das políticas de Tipos confiáveis permitidos definindo uma diretiva <code>trusted-types</code> adicional (por exemplo, <code>trusted-types myPolicy</code>). No entanto, isso não é obrigatório.  </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 require-trusted-types-for 'script', o uso de um tipo confiável é um
      requisito. O uso de qualquer API DOM perigosa com uma string resultará em um erro.
    
  
    3. 



Navegadores compatíveis



  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  


Saiba mais

X-Content-Type-Options

Quando um documento HTML malicioso é disponibilizado no seu domínio (por exemplo, se uma imagem enviada a um serviço de fotos tiver marcação HTML válida), alguns navegadores o vão tratar como um documento ativo e permitir que ele execute scripts no contexto do aplicativo, o que causa um bug de script entre sites.

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

Exemplo de uso

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

O X-Content-Type-Options: nosniff é recomendado para todos os recursos disponibilizados pelo servidor com o 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

  • 64
  • 12
  • 50
  • 11

Origem

Saiba mais

Opções de frame X

Se um site malicioso puder incorporá-lo como um iframe, isso poderá permitir que invasores invoquem ações não intencionais do usuário com clickjacking (link em inglês). Além disso, em alguns casos, ataques do tipo Spectre dão a sites maliciosos 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 <frame>, <iframe>, <embed> ou <object>. Recomendamos que todos os documentos enviem 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.

Confira nesta demonstração como as configurações a seguir afetam o carregamento de um iframe. Altere o menu suspenso X-Frame-Options e clique no botão Recarregar o iframe.

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

Negar a incorporação por qualquer outro documento.

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

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

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

X-Frame-Options: SAMEORIGIN

Navegadores compatíveis

Compatibilidade com navegadores

  • 4
  • 12
  • 4
  • 4

Origem

Saiba mais

Política de recursos de origem cruzada (CORP)

Um invasor pode incorporar recursos de outra origem, por exemplo, do seu site, para saber mais sobre eles explorando vazamentos entre sites baseados na Web.

Cross-Origin-Resource-Policy reduz esse risco, indicando o conjunto de sites em que ele pode ser carregado. O cabeçalho usa um destes três valores: same-origin, same-site e cross-origin. Recomendamos que todos os recursos enviem esse cabeçalho para indicar se eles permitem o carregamento por 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 três cabeçalhos a seguir.

Teste como as configurações a seguir afetam o carregamento de recursos em um ambiente Cross-Origin-Embedder-Policy: require-corp nesta demonstração. Altere o menu suspenso Cross-Origin-Resource-Policy e clique no botão Reload the iframe ou Reload the image para ver o efeito.

Permitir que os recursos sejam carregados cross-origin

É recomendado que serviços semelhantes a CDN apliquem cross-origin aos recursos (já que eles geralmente são carregados por páginas de origem cruzada), a menos que eles já sejam disponibilizados pelo CORS, que tem um efeito semelhante.

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

Limitar o carregamento de recursos da same-origin

same-origin precisa ser aplicado a recursos que devem ser carregados apenas por páginas de mesma origem. Aplique isso a recursos que incluam informações confidenciais sobre o usuário ou respostas de uma API que possa ser chamada somente na mesma origem.

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

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

Limitar o carregamento de recursos da same-site

É recomendado que same-site seja aplicado a recursos semelhantes aos mencionados acima, mas que precisam ser carregados por outros subdomínios do seu site.

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

Navegadores compatíveis

Compatibilidade com navegadores

  • 73
  • 79
  • 74
  • 12

Origem

Saiba mais

Política de abertura de origem cruzada (COOP)

O site de um invasor pode abrir outro site em uma janela pop-up para aprender informações sobre ele explorando vazamentos entre sites baseados na Web. Em alguns casos, isso também pode permitir a exploração de ataques de canal lateral com base no Spectre.

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

Exemplo de uso

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

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

Isolar um documento de janelas de origem cruzada

Definir same-origin coloca o documento a ser isolado das janelas de documentos de origem cruzada.

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

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

Definir same-origin-allow-popups permite que um documento retenha uma referência às janelas pop-up, a menos que ele defina COOP com same-origin ou same-origin-allow-popups. Isso significa que o same-origin-allow-popups ainda pode impedir que o documento seja referenciado quando aberto como uma janela pop-up, mas permitir que ele se comunique com os 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 você pode indicar explicitamente que esse documento pode ser aberto por uma janela de origem cruzada e manter o acesso mútuo.

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

Informar padrões incompatíveis com a COOP

É possível receber relatórios quando a COOP impede interações entre janelas com a API Reporting.

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

O COOP também oferece suporte ao modo somente relatório para que você possa receber relatórios sem 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

  • 83
  • 83
  • 79
  • 15.2

Origem

Saiba mais

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

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

Por padrão, os navegadores aplicam a política de mesma origem para impedir que uma página da Web acesse recursos de origem cruzada. Por exemplo, quando uma imagem de origem cruzada é carregada, mesmo que ela apareça visualmente na página da Web, o JavaScript na página não tem acesso aos dados da imagem. O provedor de recursos pode relaxar 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 analisar como configurar o CORS, é útil entender a distinção entre tipos de solicitação. Dependendo dos detalhes da solicitação, ela é 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 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 de origem cruzada com um cabeçalho Origin que indica a origem da solicitação.

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. Para recursos legíveis por qualquer site, é possível definir esse cabeçalho como *. Nesse caso, o navegador exigirá apenas que a solicitação seja feita sem credenciais.
  • Access-Control-Allow-Credentials: true indica que as solicitações com credenciais (cookies) podem carregar o recurso. Caso contrário, as solicitações autenticadas serão rejeitadas mesmo que a origem da solicitação esteja presente no cabeçalho Access-Control-Allow-Origin.

Veja como a solicitação simples afeta o carregamento de recursos em um ambiente Cross-Origin-Embedder-Policy: require-corp nesta demonstração. Clique na caixa de seleção Compartilhamento de recursos entre origens e no botão Recarregar a imagem para ver o efeito.

Solicitações simuladas

Uma solicitação simulada é precedida por uma solicitação OPTIONS para verificar se a solicitação seguinte tem permissão para 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 o solicitante defina os cabeçalhos HTTP X-PINGOTHER e Content-Type na solicitação seguinte.

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

Navegadores compatíveis

Compatibilidade com navegadores

  • 4
  • 12
  • 3,5
  • 4

Origem

Saiba mais

Política de incorporador de origem cruzada (COEP)

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

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

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

Exemplo de uso

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

Exemplos de uso

COEP usa um único valor de require-corp. Ao enviar esse cabeçalho, é possível instruir o navegador a bloquear o carregamento de recursos que não são ativados por meio do CORS ou CORP.

Como a COEP funciona

Confira nesta demonstração como as configurações a seguir afetam o carregamento de recursos. Altere os menus suspensos Cross-Origin-Embedder-Policy e Cross-Origin-Resource-Policy, a caixa de seleção Somente relatório etc. para ver como eles afetam o carregamento de recursos. Além disso, abra a demonstração do endpoint de relatórios para ver se os recursos bloqueados são informados.

Ativar o isolamento de origem cruzada

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

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

Informar recursos incompatíveis com a COEP

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

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

O COEP também é compatível com o modo somente relatório para que você possa receber relatórios sem realmente bloquear os recursos de carregamento.

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

Navegadores compatíveis

Compatibilidade com navegadores

  • 83
  • 83
  • 79
  • 15.2

Origem

Saiba mais

Segurança de transporte restrito HTTP (HSTS)

A comunicação por uma conexão HTTP simples não é criptografada, o que torna os dados transferidos acessíveis para curiosos no nível da rede.

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

Exemplo de uso

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

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

Strict-Transport-Security: max-age=31536000

Navegadores compatíveis

Compatibilidade com navegadores

  • 4
  • 12
  • 4
  • 7

Origem

Saiba mais

Sugestões de leitura