Um bloqueio na frente do código compactado

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

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

Available in: English, and Español
Appears in: Seguro e protegido
Eiji Kitamura
Eiji Kitamura
TwitterGitHubHomepage
Maud Nalpas
Maud Nalpas
TwitterGitHub
Artur Janc
Artur Janc
TwitterGitHub
Nesta página

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 como implementá-los em seu site e como referência para quando 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 : Cross-Origin Resource Policy (CORP) : Cross-Origin Opener Policy (COOP) : HTTP Strict Transport Security (HSTS)

Cabeçalhos de segurança para sites com recursos avançados: : Compartilhamento de recursos de origem cruzada (CORS): Política de incorporação de origem cruzada (COEP)

Ameaças conhecidas na Web

Antes de mergulhar nos cabeçalhos de segurança, aprenda sobre ameaças conhecidas na web e por que você deseja usar esses cabeçalhos de segurança.

Antes de mergulhar nos cabeçalhos de segurança, aprenda sobre ameaças conhecidas na web e por que você deseja 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 processados por seu aplicativo podem afetar seu comportamento e, comumente, levar à execução de scripts controlados pelo invasor. A vulnerabilidade mais comum causada por bugs de injeção é cross-site scripting (XSS) em suas várias formas, incluindo XSS refletido, XSS armazenado, XSS baseado em DOM e outras variantes.

Uma vulnerabilidade de 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 modelo HTML com escape automático, evitando o uso de APIs JavaScript perigosas e processando adequadamente os dados do usuário hospedando uploads de arquivos em um domínio separado e higienizando o HTML controlado pelo usuário.

Isole 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 ao documento do invasor, permitindo que o invasor modifique ou leia os dados do aplicativo.

As vulnerabilidades comuns que prejudicam o isolamento da web incluem clickjacking, falsificação de solicitação entre sites (CSRF), inclusão de script intersites (XSSI) e vários vazamentos entre sites.

Post-Specter Web Development é uma ótima leitura se você estiver interessado nesses cabeçalhos.

Crie um site poderoso com segurança #

Spectre coloca todos os dados carregados no mesmo grupo de contexto de navegação potencialmente legíveis, apesar da política de mesma origem. Os navegadores restringem recursos que podem explorar a vulnerabilidade por trás de um ambiente especial denominado "isolamento de origem cruzada". Com o isolamento de origem cruzada, você pode usar recursos poderosos, 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 invasores interceptadores 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, configuração de cookies sem o atributo Secure (ou prefixo __Secure) ou lógica de validação CORS pouco segura.

Política de segurança de conteúdo (CSP) #

Cross-Site Scripting (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.

É recomendável que você habilite o CSP estrito usando uma das seguintes abordagens:

  • Se você renderizar suas páginas HTML no servidor, use um CSP estrito baseado em nonce .
  • Se o seu HTML tiver que ser servido estaticamente ou em cache, por exemplo, se for um aplicativo de página única, use um CSP estrito baseado em hash .

Exemplo de uso: um CSP baseado em nonce

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

Usos recomendados #

1. Use um CSP estrito baseado em nonce #

Se você renderizar suas páginas HTML no servidor, use um CSP estrito baseado em nonce.

Gere um novo valor 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 nonce de todas as <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 `nonce` attribute.
</script>

O Google Fotos é um bom exemplo de CSP estrito baseado em nonce. Use DevTools para ver como ele é usado.

2. Use um CSP estrito baseado em hash #

Se o seu HTML tiver que ser servido estaticamente ou em cache, por exemplo, se você estiver construindo um aplicativo de página única, use um CSP estrito baseado 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á embutir seus scripts para aplicar uma política baseada em hash, porque a maioria dos navegadores não oferece suporte para 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 opção B: seção Cabeçalho de resposta de CSP baseado em hash.

O CSP Evaluator é uma boa ferramenta para avaliar seu CSP, mas ao mesmo tempo um bom exemplo de CSP estrito baseado em nonce. Use DevTools para ver como ele é usado.

Chrome, Firefox, Edge, Safari

Vejamais compatibilidades.

Outras coisas a serem observadas sobre CSP #

  • 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, pode usar X-Frame-Options para bloquear o carregamento, mas frame-ancestors oferecem uma configuração avançada para permitir apenas origens específicas como incorporadores.
  • Você pode ter usado um 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 um CSP no modo somente relatório.
  • Se você não pode definir um CSP como um cabeçalho do lado do servidor, você também pode defini-lo como uma metatag. Observe que você não pode usar o modo somente relatório para metatags (embora isso possa mudar).

Saber mais #

Tipos confiáveis #

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

Tipos confiáveis fornecem as ferramentas para escrever, revisar a segurança e manter aplicativos livres de DOM XSS. Eles podem ser ativados via 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, você pode definir políticas de segurança nas quais pode garantir que as regras de segurança (como escape ou sanitização) sejam aplicadas de forma consistente antes que os dados sejam gravados no DOM. Essas políticas são, então, os únicos lugares no código que podem potencialmente 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, '<').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;  // '<img src=x onerror=alert(1)>'
Como usar tipos confiáveis

Usos recomendados #

  1. Aplicar tipos confiáveis para coletores DOM perigosos

    CSP e cabeçalho de tipos confiáveis:

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

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

    Claro, você pode combinar Tipos confiáveis com outras diretivas CSP:

    Mesclando um CSP baseado em nonce de cima com tipos confiáveis:

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

  2. Defina uma política

    Política do

    :

    // 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;');
        }
      });
    }

  3. Aplicar a política

    Use a política ao gravar dados no DOM:

    // Assignment of raw strings are 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;'

    Com require-trusted-types-for 'script', usar um tipo confiável é um requisito. Usar qualquer API DOM perigosa com uma string resultará em um erro.

Chrome, Edge

Veja mais compatibilidades.

Saber mais #

X-Content-Type-Options #

Quando um documento HTML malicioso é veiculado em seu domínio (por exemplo, se uma imagem carregada em um serviço de fotos contém marcação HTML válida), alguns navegadores o tratam como um documento ativo e permitem que ele execute scripts no contexto do aplicativo, levando a um bug de script entre sites.

X-Content-Type-Options: nosniff evita isso instruindo o navegador de que o tipo MIME definido no Content-Type para 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

Usos recomendados #

X-Content-Type-Options: nosniff é recomendado para todos os recursos servidos pelo seu servidor junto com o cabeçalho Content-Type

X-Content-Type-Options: nosniff

Cabeçalhos de exemplo enviados com um documento HTML

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

Chrome, Firefox, Safari, Edge

Veja mais compatibilidades.

Saber mais #

Opções de X-Frame #

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

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

Exemplo de uso

X-Frame-Options: DENY
Como usar as opções do X-Frame

Usos recomendados #

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

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

Protege o seu site de ser incorporado por qualquer outro site #

Negar ser incorporado por qualquer outro documento.

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

Protege seu site de ser incorporado por qualquer site de origem cruzada #

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

X-Frame-Options: SAMEORIGIN

Chrome, Firefox, Safari, Edge

Veja mais compatibilidades.

Saber mais #

Política de recursos de origem cruzada (CORP) #

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

Cross-Origin-Resource-Policy mitiga esse risco, indicando o conjunto de sites pelos quais ele pode ser carregado. O cabeçalho assume um de três valores: same-origin, same-site e cross-origin. Todos os recursos são recomendados para enviar este cabeçalho para indicar se eles permitem ser carregados por outros sites.

Exemplo de uso

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

Usos recomendados #

É recomendável que todos os recursos sejam servidos com um dos três cabeçalhos a seguir.

Você pode experimentar 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 Recarregar o iframe ou Recarregar a imagem para ver o efeito.

Permitir que recursos sejam carregados cross-origin #

Recomenda-se que os serviços do tipo CDN apliquem cross-origin aos recursos (uma vez que geralmente são carregados por páginas de origem cruzada), a menos que já sejam servidos por meio do CORS, que tem um efeito semelhante.

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

Limite os recursos a serem carregados da same-origin #

same-origin deve ser aplicada a recursos que devem ser carregados apenas por páginas da mesma origem. Você deve aplicar isso a recursos que incluem informações confidenciais sobre o usuário ou respostas de uma API que se destina a ser chamada apenas da mesma origem.

Lembre-se de que os recursos com este cabeçalho ainda podem ser carregados diretamente, por exemplo, navegando para o URL em uma nova janela do navegador. A Política de Recursos de Origem Cruzada protege apenas o recurso de ser incorporado por outros sites.

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

Limite os recursos a serem carregados do same-site #

same-site é recomendado para ser aplicado a recursos semelhantes aos anteriores, mas que devem ser carregados por outros subdomínios de seu site.

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

Chrome, Firefox, Safari, Edge

Veja mais compatibilidades.

Saber mais #

Política de abertura de origem cruzada (COOP) #

O site de um invasor pode abrir outro site em uma janela pop-up para obter 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 baseados em Spectre.

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

Exemplo de uso

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

Usos recomendados #

Você pode tentar como as configurações a seguir afetam a comunicação com uma janela pop-up de origem cruzada nesta demonstração. 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, em seguida, clique em Enviar uma postMessage para confirmar se a mensagem foi realmente entregue.

Isole um documento de janelas de origem cruzada #

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

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

Isola um documento de janelas de origem cruzada, mas permite pop-ups #

Definir same-origin-allow-popups permite que um documento retenha uma referência a suas janelas pop-up, a menos que eles definam COOP como 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 permite 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 você pode indicar explicitamente que este documento pode ser aberto por uma janela de origem cruzada e manter o acesso mútuo.

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

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

Você pode receber relatórios quando o COOP impede interações entre janelas com a API de relatórios.

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

O COOP também oferece suporte a um modo somente relatório para que você possa receber relatórios sem realmente bloquear a comunicação entre documentos de origem cruzada.

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

Chrome, Firefox, Edge

Veja mais compatibilidades.

Saber mais #

Compartilhamento de recursos de origem cruzada (CORS) #

Ao contrário de outros itens neste artigo, Cross-Origin Resource Sharing (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 impõem a política de mesma origem para evitar que uma página da web acesse recursos de origem cruzada. Por exemplo, quando uma 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 relaxar as restrições e permitir que outros sites leiam o recurso optando pelo CORS.

Exemplo de uso

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

Antes de examinar como configurar o CORS, é útil entender a distinção entre os tipos de solicitação. Dependendo dos detalhes do pedido, um pedido será classificado como um pedido simples ou um pedido preflight.

Critérios para um pedido 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 preflight. Para obter 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 de origem cruzada com um 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 https://example.com pode acessar o conteúdo da resposta. Os recursos que devem ser lidos por qualquer site podem definir esse cabeçalho como *, caso em que o navegador exigirá apenas que a solicitação seja feita sem credenciais.
  • Access-Control-Allow-Credentials: true indica que as solicitações que carregam credenciais (cookies) têm permissão para carregar o recurso. Caso contrário, as solicitações autenticadas serão rejeitadas mesmo se a origem da solicitação estiver presente no cabeçalho Access-Control-Allow-Origin

Você pode experimentar 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 de origem cruzada e clique no botão Recarregar a imagem para ver o efeito.

Solicitações comprovadas #

Uma solicitação preflight é precedida de uma OPTIONS para verificar se a solicitação subsequente 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 seguinte solicitação seja feita com o método POST
  • Access-Control-Request-Headers: X-PINGOTHER, Content-Type permite que o solicitante defina os X-PINGOTHER e Content-Type na solicitação subsequente.

Cabeçalhos de resposta de exemplo

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 preflight pode ser armazenado em cache por 86400 segundos.

Chrome, Firefox, Safari, Edge

Veja mais compatibilidades.

Saber mais #

Política de incorporação de origem cruzada (COEP) #

Para reduzir a capacidade dos ataques baseados em Spectre para roubar recursos de origem cruzada, recursos como SharedArrayBuffer, performance.measureUserAgentSpecificMemory() ou API JS Self Profiling são desabilitados 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 meio de cabeçalhos CORS ou CORP. O COEP pode ser combinado com Cross-Origin-Opener-Policy para permitir que um documento seja isolado de origem cruzada.

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

Exemplo de uso

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

Exemplos de uso #

COEP assume 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 optem por meio de CORS ou CORP.

Como a COEP funciona

Você pode experimentar como as configurações a seguir afetam o carregamento de recursos nesta demonstração. Altere o menu suspenso Cross-Origin-Embedder-Policy, o menu suspenso Cross-Origin-Resource-Policy, a caixa de seleção Apenas relatório e afins para ver como eles afetam o carregamento de recursos. Além disso, abra a demonstração do endpoint de relatório para ver se os recursos bloqueados são relatados.

Ativar isolamento de origem cruzada #

Habilite 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

Reportar recursos incompatíveis com o COEP #

Você pode receber relatórios de recursos bloqueados causados pelo COEP com a API de relatórios.

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

O COEP também oferece suporte ao 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"

Chrome, Firefox, Edge

Veja mais compatibilidades.

Saber mais #

Segurança de transporte estrita HTTP (HSTS) #

A comunicação em uma conexão HTTP simples não é criptografada, tornando os dados transferidos acessíveis para bisbilhoteiros no nível da rede.

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 HSTS

Usos recomendados #

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

Strict-Transport-Security: max-age=31536000

Chrome, Firefox, Safari, Edge

Veja mais compatibilidades.

Saber mais #

Leitura adicional #

Last updated

— Improve article
Return to all articles
Compartilhar
By Chrome DevRel