Como revisar cabeçalhos de segurança em um site criado por IA

Um site criado por IA pode chegar ao deploy com HTML limpo e ainda responder sem políticas importantes do navegador. Também pode herdar um arquivo de outro projeto, bloquear um formulário legítimo ou liberar recursos para qualquer origem só para fazer uma integração funcionar.

Revisar cabeçalhos de segurança não é colar uma lista pronta até uma ferramenta mostrar nota máxima. É entender o que a página carrega, escolher políticas compatíveis com esse comportamento e confirmar a resposta que o navegador realmente recebe.

Este guia organiza a revisão da fonte à URL publicada, com atenção especial a sites estáticos e landing pages.

O que os cabeçalhos conseguem proteger

Cabeçalhos HTTP permitem que a resposta declare regras ao navegador. Eles podem reduzir exposição a carregamento indevido de recursos, interpretação incorreta de tipos de arquivo, incorporação em frames e envio excessivo de informações no referrer.

Eles não substituem:

• remoção de segredos do frontend;
• atualização de dependências;
• validação no backend;
• autenticação e autorização;
• revisão dos scripts de terceiros;
• TLS e DNS corretamente configurados;
• testes reais da aplicação.

Se uma chave privada entrou no JavaScript público, nenhum cabeçalho volta a torná-la secreta. Comece pelo guia sobre chaves de API e segredos em sites criados por IA.

Faça um inventário antes de configurar

Registre o comportamento atual da página:

URL publicada:
versão ou commit:
pasta publicável:
scripts próprios:
scripts de terceiros:
fontes externas:
imagens externas:
destinos de formulário:
requisições fetch ou WebSocket:
iframes e embeds:
recursos do navegador usados:

Compare fonte, build e rede no navegador. Uma URL presente no código pode ter sido removida pela build; outra pode ser criada dinamicamente apenas depois de uma interação.

O inventário evita duas falhas opostas:

1. política permissiva demais, criada para acomodar origens que o site nem usa;
2. política restritiva demais, que quebra recursos legítimos depois da publicação.

Para cada serviço externo, registre responsável, finalidade, dados enviados e evidência de que ainda é necessário. O checklist de scripts de terceiros em landing pages ajuda a fechar essa parte.

Revise os cabeçalhos por função

Não existe um bloco universal para qualquer site. Comece pelos controles que correspondem ao risco e à arquitetura encontrados.

Content-Security-Policy

Content-Security-Policy controla origens e tipos de recursos que a página pode carregar. É o cabeçalho com maior alcance e também o que mais facilmente quebra uma página quando copiado sem inventário.

Use-o para restringir scripts, estilos, imagens, conexões, frames e envio de formulários. O guia de Content Security Policy para landing pages mostra como construir e testar a política em etapas.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Esse valor pede que o navegador respeite os tipos MIME declarados, em vez de tentar reinterpretar conteúdo. A referência do MDN sobre X-Content-Type-Options também ressalta que scripts e estilos podem ser bloqueados quando chegam com tipo incompatível.

Por isso, não pare depois de adicionar nosniff: confirme que HTML, CSS, JavaScript, fontes e imagens são servidos com Content-Type correto.

Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Referrer-Policy controla quanto do endereço atual pode acompanhar uma navegação ou requisição. A referência do MDN descreve as diferenças entre enviar URL completa, somente a origem ou nenhum referrer.

Escolha com base em privacidade e medição. Uma política mais restrita pode reduzir dados disponíveis em ferramentas externas; uma política permissiva pode expor caminhos e parâmetros desnecessários.

Permissions-Policy

Permissions-Policy limita recursos do navegador, como câmera, microfone e geolocalização. Uma landing page que não usa essas capacidades pode desativá-las explicitamente:

Permissions-Policy: camera=(), microphone=(), geolocation=()

Não bloqueie uma capacidade sem verificar embeds e jornadas reais. Um agendador ou videochamada incorporada pode depender de permissões que a página principal não usa diretamente.

Proteção contra incorporação

Se a página não deve aparecer dentro de um iframe, prefira expressar isso na CSP:

Content-Security-Policy: frame-ancestors 'none'

X-Frame-Options: DENY ainda pode ser usado como compatibilidade, mas não oferece a mesma granularidade. Se o site precisa ser incorporado por um domínio parceiro, DENY contradiz o requisito; defina os ancestrais aprovados na CSP.

Strict-Transport-Security

HSTS informa ao navegador que um hostname deve ser acessado somente por HTTPS durante um período. É uma decisão de domínio, não um item para ligar automaticamente em qualquer preview.

Antes de incluir includeSubDomains ou solicitar preload, confirme que todos os subdomínios relevantes suportam HTTPS de forma permanente. Uma configuração ampla e prematura pode tornar serviços legítimos inacessíveis.

Não confunda segurança com CORS

Access-Control-Allow-Origin controla quais origens podem ler determinadas respostas em requisições cross-origin. Adicionar * não “corrige segurança”; pode ampliar acesso onde a resposta deveria ser restrita.

Uma página estática comum não precisa liberar todos os assets ou endpoints para qualquer origem. Para APIs, credenciais e requisições OPTIONS, a política pertence ao servidor que produz a resposta, não a um arquivo estático copiado para o site.

Registre a origem exata que precisa de acesso e teste os métodos, cabeçalhos e credenciais envolvidos.

Confirme onde os headers podem ser configurados

O contrato atual de Publicação do Site no Ar envia páginas e assets, mas não interpreta um arquivo _headers colocado no pacote. Um arquivo com esse nome pode até chegar à build sem produzir os cabeçalhos esperados.

Se a página precisa de headers personalizados, registre a exigência e confirme uma camada autorizada que controle a resposta HTTP, como um proxy ou origem administrada pela equipe, ou uma capacidade explicitamente oferecida pela plataforma. Configure a política nessa camada, não em um arquivo que o fluxo de publicação ignora.

Enquanto essa capacidade não existir, não marque o controle como implementado. Alguns comportamentos têm alternativas limitadas no HTML, mas elas não reproduzem todos os headers: CSP em <meta> não suporta report-only nem frame-ancestors, HSTS só existe como header e políticas de resposta continuam pertencendo ao servidor.

Teste localmente sem presumir o deploy

Primeiro valide a sintaxe e inspecione a saída. Depois rode os testes funcionais do projeto. Para cada política, liste uma jornada que poderia ser afetada:

Uma ferramenta automática ajuda a encontrar ausências, mas não prova que os valores são corretos nem que a página continua funcionando.

Publique e inspecione a resposta real

O contrato de Publicação publica os arquivos dentro de public/, mas a camada autorizada para alterar headers precisa ser confirmada separadamente.

Depois do deploy, inspecione a resposta sem confundir o HTML com seus headers:

curl -sS -D - -o /dev/null https://exemplo.sitenoar.app/

Repita para uma rota interna, um arquivo CSS e um JavaScript. Confirme:

• status esperado;
• Content-Type coerente;
• cabeçalhos presentes uma única vez;
• valor final sem junções inesperadas;
• nenhuma política antiga herdada;
• funcionamento do formulário, menu e integrações;
• console sem bloqueios desconhecidos;
• mesma resposta no domínio próprio, quando houver.

Headers definidos mais de uma vez podem ser combinados de forma diferente do esperado. Revise regras globais e específicas que correspondem à mesma URL.

Corrija e republique o mesmo Site

Se uma política bloquear um recurso legítimo, não remova toda a proteção nem adicione * por reflexo. Identifique a diretiva, confirme a origem e escolha entre remover o recurso, hospedá-lo no próprio site ou autorizar somente o necessário.

Depois, gere outra build e republique o mesmo Site. Preserve Site ID, slug e domínio para comparar a versão anterior com a corrigida.

Registre:

Site ID:
versão anterior:
versão revisada:
cabeçalhos alterados:
jornadas testadas:
URLs verificadas:
exceções aceitas e responsáveis:

Prompt copiável para o agente

Revise os cabeçalhos de segurança deste site sem publicar alterações ainda.

Fonte: [caminho]
Pasta publicável: [pasta]
URL atual: [URL]
Domínio próprio: [hostname, se houver]
Integrações aprovadas: [lista]

Entregue:
- inventário de recursos e origens realmente usados;
- headers encontrados na fonte, build e URL;
- risco e compatibilidade de cada valor;
- jornadas que cada mudança pode afetar;
- correção mínima proposta na fonte;
- plano de validação antes e depois do deploy.

Não adicione CORS com wildcard.
Não habilite HSTS para subdomínios sem confirmação.
Não copie uma CSP genérica.
Não publique até eu aprovar o diff e os testes.

Checklist final

• recursos e origens inventariados;
• políticas escolhidas por função;
• CSP tratada separadamente;
• tipos MIME conferidos com nosniff;
• política de referrer aprovada;
• capacidades do navegador revisadas;
• necessidade de iframe confirmada;
• CORS não foi ampliado sem requisito;
• camada responsável pelos headers foi confirmada;
• jornadas críticas passaram antes do deploy;
• headers da URL publicada foram inspecionados;
• domínio próprio e rotas internas foram testados;
• evidências ficaram ligadas à versão publicada.

Cabeçalhos de segurança úteis não são uma coleção de selos. Eles transformam o comportamento real do site em regras verificáveis para o navegador. Quando inventário, build, resposta e testes contam a mesma história, a proteção deixa de ser decorativa e passa a fazer parte da entrega.