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

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

Eiji Kitamura

Artur Janc

Maud Nalpas

Este artigo lista os cabeçalhos de segurança mais importantes que você pode usar para proteger seu site. Use-o para entender os recursos de segurança baseados na Web, aprender a implementá-los no seu site e como referência quando precisar de um lembrete.

Cabeçalhos de segurança recomendados para sites que processam dados do usuário sensíveis:: 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 de origem cruzada (CORP); Política de abertura de origem cruzada (COOP); HTTP Strict Transport Security (HSTS)
Cabeçalhos de segurança para sites com recursos avançados:: Compartilhamento de recursos entre origens (CORS); Política de incorporação entre origens (COEP)

Ameaças conhecidas na Web

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

Proteja seu site contra vulnerabilidades de injeção

As 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 sites (XSS) em suas várias formas, incluindo XSS refletido, XSS armazenado, XSS baseado em DOM e outras variantes.

Uma vulnerabilidade XSS geralmente dá 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 corretamente os dados do usuário ao hospedar uploads de arquivos em um domínio separado e higienizar 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 seu aplicativo e reduzir o risco de injeções.
Use Trusted Types para aplicar a limpeza de dados transmitidos a 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 de scripts.

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 inesperadamente ou incorporar dados de outro aplicativo no documento do invasor, permitindo que ele modifique ou leia dados do aplicativo.

Vulnerabilidades comuns que prejudicam o isolamento da Web incluem roubo de cliques, falsificação de solicitação entre sites (CSRF), inclusão de script entre sites (XSSI) e vários vazamentos entre sites.

Use X-Frame-Options para evitar que seus documentos sejam incorporados por um site malicioso.
Use a Política de recursos entre origens (CORP) para impedir que os recursos do seu site sejam incluídos por um site de origem cruzada.
Use a política de abertura entre origens (COOP) para proteger as janelas do seu site contra interações de sites maliciosos.
Use o Compartilhamento de recursos entre origens (CORS) para controlar o acesso aos recursos do seu site em documentos de origem cruzada.

Post-Spectre Web Development (em inglês) é uma ótima leitura se você tiver interesse nesses cabeçalhos.

Crie um site eficiente e seguro

O Spectre coloca todos os dados carregados no mesmo grupo de contexto de navegação, que pode ser lido 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 entre origens". Com o isolamento entre origens, você pode usar recursos avançados, como SharedArrayBuffer.

Use a Política de incorporador entre origens (COEP) com a COOP para ativar o isolamento entre origens.

Criptografar o tráfego para seu site

Problemas de criptografia aparecem quando um aplicativo não criptografa totalmente os dados em trânsito, permitindo que invasores espiões saibam 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 o prefixo __Secure) ou lógica de validação CORS flexível.

Use o HTTP Strict Transport Security (HSTS) para veicular seus conteúdos de forma consistente por HTTPS.

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

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

O Content-Security-Policy oferece uma camada extra para reduzir ataques de XSS, restringindo quais scripts podem ser executados pela página.

Recomendamos que você ative a CSP estrita usando uma das seguintes abordagens:

Se você renderizar suas páginas HTML no servidor, use uma CSP rigorosa baseada em valor de uso único.
Se o HTML precisar ser veiculado de forma estática ou armazenado em cache, por exemplo, se for um aplicativo de página única, use uma CSP estrita baseada em hash.

Exemplo de uso: uma CSP baseada em nonce

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

Como usar o CSP

Usos recomendados

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

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

Gere um novo valor de nonce de 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> como 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 estrita baseada em valor de uso único. Use o DevTools para ver como ele é usado.

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

Se o HTML precisar ser veiculado de forma estática ou armazenado 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, é necessário inserir os scripts inline para aplicar uma política baseada em hash, porque a maioria dos navegadores não oferece suporte a hash de scripts externos.

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 CSP Evaluator é uma boa ferramenta para avaliar sua CSP e, ao mesmo tempo, um bom exemplo de CSP estrita baseada em nonce. Use o DevTools para ver como ele é usado.

Navegadores compatíveis

* https: é um substituto para o Safari, e unsafe-inline é um substituto para versões muito antigas de navegadores. https: e unsafe-inline não tornam sua política menos segura porque serão ignorados pelos navegadores que oferecem suporte a strict-dynamic. Leia mais em Adicionar substitutos para oferecer suporte ao Safari e navegadores mais antigos. * O Safari não é compatível com strict-dynamic. Mas um CSP estrito, como nos exemplos acima, é mais seguro do que um CSP de lista de permissões (e muito mais seguro do que nenhum CSP) para todos os seus usuários. Mesmo no Safari, uma CSP estrita protege seu site de alguns tipos de ataques XSS, porque a presença da CSP não permite determinados padrões não seguros.

Outros pontos importantes sobre o 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 preferir uma solução mais simples, use X-Frame-Options para bloquear o carregamento, mas 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 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á defini-la como uma metatag. Não é possível usar o modo somente relatório para metatags, mas isso pode mudar.

Saiba mais

Tipos confiáveis

O XSS baseado em DOM é um ataque em que dados maliciosos são transmitidos para um coletor que oferece suporte à execução dinâmica de código, como eval() ou .innerHTML.

Os tipos confiáveis oferecem as ferramentas para escrever, revisar a segurança e manter aplicativos livres de DOM XSS. Eles podem ser ativados via CSP e proteger o código JavaScript por padrão, limitando as APIs da Web perigosas para aceitar apenas um objeto especial: um tipo confiável.

Para criar esses objetos, defina políticas de segurança que garantam que as regras de segurança (como escape ou limpeza) sejam aplicadas de forma consistente antes que os dados sejam gravados no DOM. Essas políticas são os únicos lugares no código que podem introduzir 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

Usos recomendados

Aplicar Tipos confiáveis para receptores DOM perigosos Cabeçalho da CSP e de 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.

É claro que você pode combinar tipos confiáveis com outras diretivas da CSP:

Como mesclar uma CSP baseada em nonce 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 de 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>


  
    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, '>');
    }
  });
}
    Observação : é possível definir políticas com nomes arbitrários, a menos que você limite os nomes das políticas de tipos confiáveis permitidas definindo a diretiva trusted-types. 
  
  
    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', usar um tipo confiável é um
      requisito. Usar qualquer API DOM perigosa com uma string vai resultar em um
      erro.
  

Navegadores compatíveis

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
    
    
    
  
Saiba mais

  Evitar vulnerabilidades de scripting em vários sites baseadas em DOM com Tipos
      Confiáveis
  CSP: require-trusted-types-for - HTTP |
      MDN
  CSP: trusted-types - HTTP |
      MDN
  Demonstração de tipos confiáveis: abra o inspetor do DevTools e veja o que está acontecendo.



X-Content-Type-Options

Quando um documento HTML malicioso é disponibilizado do seu domínio (por exemplo, se uma imagem enviada para um serviço de fotos contém uma marcação HTML válida), alguns navegadores o tratam como um documento ativo e permitem que ele execute scripts no contexto do aplicativo, resultando em um scripting em vários sites.

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

Exemplo de uso
X-Content-Type-Options: nosniff


  
    
    Como usar X-Content-Type-Options


    
      Usos recomendados
O X-Content-Type-Options: nosniff é recomendado para todos os recursos veiculados do
  servidor, junto com o cabeçalho Content-Type correto.

Exemplo de cabeçalhos enviados com um HTML de documento
X-Content-Type-Options: nosniff
Content-Type: text/html; charset=utf-8
Navegadores compatíveis

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        64
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        50
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        11
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Saiba mais

  X-Content-Type-Options - HTTP MDN

    
  


X-Frame-Options

Se um site malicioso puder incorporar seu site como um iframe, isso permitirá que
invasores invoquem ações não intencionais do usuário com
clickjacking. Além disso, em alguns casos, ataques do tipo Spectre dão aos sites maliciosos a chance de saber o conteúdo de um documento incorporado.

X-Frame-Options indica se um navegador pode ou não renderizar
uma página em um <frame>, <iframe>, <embed> ou <object>. Todos os documentos
são recomendados para enviar esse cabeçalho e indicar se permitem ser
incorporados por outros documentos.

Observação : se você precisar de um controle mais granular, como permitir que apenas uma origem específica incorpore o documento, use a diretiva CSP frame-ancestors.  

Exemplo de uso
X-Frame-Options: DENY


  
    
    Como usar X-Frame-Options


    
      Usos recomendados
Todos os documentos que não foram projetados para serem incorporados precisam usar o cabeçalho X-Frame-Options.
Teste como as configurações a seguir afetam o carregamento de um iframe nesta demonstração. Mude o menu suspenso X-Frame-Options
  e clique no botão Atualizar o iframe.
Protege seu site contra incorporação por outros sites.
Negar ser incorporado por outros documentos.

X-Frame-Options: DENY
Protege seu site contra incorporação por sites de origem cruzada.
Permite incorporação apenas por documentos da mesma origem.
X-Frame-Options: SAMEORIGIN
 O fato de os documentos serem incorporáveis por padrão significa que os desenvolvedores da Web precisam enviar explicitamente DENY ou SAMEORIGIN para impedir a incorporação e se proteger contra ataques de canal lateral. A equipe do Chrome está considerando mudar para o bloqueio de incorporações de documentos por padrão. Assim, os sites serão seguros mesmo que não definam explicitamente o cabeçalho. Nesse novo mundo, os documentos precisariam ativar explicitamente a incorporação. 
Navegadores compatíveis

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Saiba mais

  X-Frame-Options: HTTP

    
  


Política de recursos entre origens (CORP)

Um invasor pode incorporar recursos de outra origem, por exemplo, do seu site, para aprender informações sobre eles explorando vazamentos entre sites baseados na Web.

O 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. Todos os recursos são recomendados para enviar esse cabeçalho e indicar se permitem o carregamento por outros sites.

Exemplo de uso
Cross-Origin-Resource-Policy: same-origin


  
    
    Como usar o CORP


    
      Usos recomendados
Recomendamos que todos os recursos sejam veiculados 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. Mude o menu suspenso Cross-Origin-Resource-Policy e clique no botão Recarregar o iframe ou Recarregar a imagem para ver o efeito.

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

Cross-Origin-Resource-Policy: cross-origin
Limitar os recursos a serem carregados do same-origin
O same-origin precisa ser aplicado a recursos que devem ser carregados apenas
  por páginas de mesma origem. Isso deve ser aplicado a recursos que incluem informações sensíveis sobre o usuário ou respostas de uma API que deve ser chamada apenas da mesma origem.
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 entre origens protege apenas o recurso contra incorporação por outros sites.

Cross-Origin-Resource-Policy: same-origin
Limitar os recursos a serem carregados do same-site
Recomendamos que same-site seja aplicado a recursos semelhantes aos acima, mas que serão carregados por outros subdomínios do site.

Cross-Origin-Resource-Policy: same-site
Observação : para saber mais sobre a diferença entre mesma origem e mesmo site, confira Entenda "mesmo site" e "mesma origem". 
Navegadores compatíveis

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        73
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        74
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Saiba mais

  Considere implantar uma política de recursos de origem cruzada
  Como tornar seu site "isolado de origem cruzada" usando COOP e COEP
  Por que você precisa de "isolamento de origem cruzada" para recursos avançados

    
  


Política de abertura entre origens (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 permite que um documento se isole 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á referência a ele e não poderá interagir
com ele.

Exemplo de uso
Cross-Origin-Opener-Policy: same-origin-allow-popups


  
    
    Como usar o COOP


    
      Usos recomendados
Teste como as configurações a seguir afetam a comunicação com uma
  janela pop-up de origem cruzada nesta demonstração.
  Mude o menu suspenso Cross-Origin-Opener-Policy para o documento e a janela pop-up, clique no botão Abrir um pop-up e em Enviar um postMessage para verificar se a mensagem foi entregue.
Isolar um documento de janelas de origens diferentes
A configuração same-origin isola o documento de janelas de documentos entre origens.

Cross-Origin-Opener-Policy: same-origin
Isolar um documento de janelas entre origens, mas permitir pop-ups
A definição de same-origin-allow-popups permite que um documento mantenha uma referência às janelas pop-up, a menos que elas definam COOP com same-origin ou same-origin-allow-popups. Isso significa que o same-origin-allow-popups ainda pode proteger o documento contra referências 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
Permitir que um documento seja referenciado por janelas de origens diferentes
unsafe-none é o valor padrão, mas você pode indicar explicitamente que este documento pode ser aberto por uma janela de origem cruzada e manter o acesso mútuo.

 unsafe-none ser o padrão significa que os desenvolvedores da Web precisam enviar same-origin ou same-origin-allow-popups explicitamente para proteger o site contra ataques de canal lateral. 
Cross-Origin-Opener-Policy: unsafe-none
Observação : recursos como SharedArrayBuffer ou performance.measureUserAgentSpecificMemory() são desativados por padrão. Alguns navegadores permitem o uso em contextos de isolamento de origem cruzada, que exigem a definição de cabeçalhos COOP e COEP. Para saber mais, leia Como isolar a origem cruzada do seu site usando COOP e COEP. 
Informar padrões incompatíveis com COOP
Você pode 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 a um modo somente relatório para que você receba relatórios sem
  bloquear a comunicação entre documentos de origens diferentes.
Cross-Origin-Opener-Policy-Report-Only: same-origin; report-to="coop"
Navegadores compatíveis

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Saiba mais

  Por que você precisa de "isolamento de origem cruzada" para recursos avançados

    
  


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 do navegador que solicita e permite o acesso a recursos de origens diferentes.

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 seja exibida visualmente na página da Web, 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 aprender a configurar o CORS, é útil entender a distinção entre os tipos de solicitação. Dependendo dos detalhes, uma solicitação será classificada como simples ou comprovada.
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 resto é classificado como uma solicitação de pré-verificação. Para mais detalhes, consulte Compartilhamento de recursos entre origens (CORS) – HTTP |
    MDN.
Usos recomendados
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 origem
  da solicitação.
Exemplo de cabeçalho da 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. Os recursos destinados
    a serem legíveis por qualquer site podem definir esse cabeçalho como *. Nesse caso, o
    navegador só vai exigir que a solicitação seja feita sem
      credenciais.
  
  Access-Control-Allow-Credentials: true indica que as solicitações que carregam
    credenciais (cookies) podem carregar o recurso. Caso contrário, as solicitações autenticadas serão rejeitadas, mesmo que a origem solicitante esteja presente no cabeçalho Access-Control-Allow-Origin.

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

Solicitações de simulação
Uma solicitação simulada é precedida por uma solicitação OPTIONS para verificar se a
  solicitação subsequente pode ser enviada.
Exemplo de cabeçalho da solicitação
OPTIONS / HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

  O Access-Control-Request-Method: POST permite que a seguinte solicitação 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 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 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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        3.5
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Saiba mais

  Compartilhamento de recursos entre origens (CORS)
  Compartilhamento de recursos entre origens (CORS) - HTTP |
      MDN

    
  


Política de incorporador entre origens (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 por serem carregados por cabeçalhos CORS ou CORP. O COEP pode ser combinado comCross-Origin-Opener-Policy
para ativar um documento no isolamento entre origens.

Use Cross-Origin-Embedder-Policy: require-corp quando quiser ativar o
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
  instruir o navegador a bloquear o carregamento de recursos que não ativam
  o CORS ou o CORP.


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

Ativar o isolamento entre origens
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 o COEP
Você pode receber relatórios de recursos bloqueados causados pela COEP com a API Reporting.
Cross-Origin-Embedder-Policy: require-corp; report-to="coep"
A COEP também oferece suporte ao modo somente relatório para que você receba relatórios sem bloquear o carregamento de recursos.
Cross-Origin-Embedder-Policy-Report-Only: require-corp; report-to="coep"
Navegadores compatíveis

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        83
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        79
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        15.2
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Saiba mais

  Como tornar seu site "isolado de origem cruzada" usando COOP e COEP
  Por que você precisa de "isolamento de origem cruzada" para recursos avançados
  Um guia para ativar o isolamento de origem cruzada

    
  


HTTP Strict Transport Security (HSTS)

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

O cabeçalho Strict-Transport-Security informa ao navegador que ele nunca deve carregar
o site usando HTTP e, em vez disso, usar 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


    
      Usos recomendados
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

  
    
    
    
    
  
  
  
    
      
    
  
    
      
    
  
    
      
    
   

    
    
      
      

        Browser Support
        
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        12
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        4
      
    
  
  
  
          
  
  
    
      
        
          
          
        
      
    
    
  

  
  
  
  
    
  
  
  
    
  

  
    
    
      
        7
      
    
  
  
  
        
        
        Source
        
      
    
    
    
  
Saiba mais

  Strict-Transport-Security -
      HTTP

    
  


Leitura adicional


Desenvolvimento da Web pós-Spectre

Referência rápida sobre cabeçalhos de segurança Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Proteja seu site contra vulnerabilidades de injeção

Isolar seu site de outros sites

Crie um site eficiente e seguro

Criptografar o tráfego para seu site

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

Usos recomendados

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

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

Navegadores compatíveis

Outros pontos importantes sobre o CSP

Saiba mais

Tipos confiáveis

Usos recomendados

Navegadores compatíveis

Saiba mais

X-Content-Type-Options

Usos recomendados

Navegadores compatíveis

Saiba mais

X-Frame-Options

Usos recomendados

Protege seu site contra incorporação por outros sites.

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

Navegadores compatíveis

Saiba mais

Política de recursos entre origens (CORP)

Usos recomendados

Permitir que os recursos sejam carregados cross-origin

Limitar os recursos a serem carregados do same-origin

Limitar os recursos a serem carregados do same-site

Navegadores compatíveis

Saiba mais

Política de abertura entre origens (COOP)

Usos recomendados

Isolar um documento de janelas de origens diferentes

Isolar um documento de janelas entre origens, mas permitir pop-ups

Permitir que um documento seja referenciado por janelas de origens diferentes

Informar padrões incompatíveis com COOP

Navegadores compatíveis

Saiba mais

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

Usos recomendados

Solicitação simples

Solicitações de simulação

Navegadores compatíveis

Saiba mais

Política de incorporador entre origens (COEP)

Exemplos de uso

Ativar o isolamento entre origens

Informar recursos incompatíveis com o COEP

Navegadores compatíveis

Saiba mais

HTTP Strict Transport Security (HSTS)

Usos recomendados

Navegadores compatíveis

Saiba mais

Leitura adicional

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

Permitir que os recursos sejam carregados `cross-origin`

Limitar os recursos a serem carregados do `same-origin`

Limitar os recursos a serem carregados do `same-site`