Segurança do site, parte 3: cabeçalhos de segurança e CSP

Na parte anterior eu contei como protegi o nome do domínio: DNSSEC, registros contra e-mail falso, CAA, Bot Fight Mode e o redirecionamento do www. Agora o foco sai do registro do nome e vai para as conversas entre o servidor e o navegador de quem lê.

O que eu queria resolver

Em 3 de outubro de 2026 o meu site pessoal entrou no ar em rodrigoesporto.com. O cadeado já estava ativo e o endereço estava seguro. Só que um site moderno não entrega apenas texto puro. Ele envia ordens técnicas para o programa que você usa para navegar, seja no celular ou no computador.

Se você não define essas ordens com clareza, o navegador adota comportamentos padrão que costumam ser permissivos demais. Um site desavisado pode ser embutido dentro de outra página sem autorização, ou aceitar códigos externos que ninguém pediu. Eu queria que o meu site avisasse expressamente ao navegador o que é permitido e o que está proibido, fechando portas para abusos sem cobrar nada por isso e sem alterar em nada a leitura de quem visita a página.

Trabalho durante o dia e, à noite e aos domingos, construo com agentes de IA. No painel da Cloudflare, eu fiz as configurações necessárias enquanto o Darth conferia de fora. O Darth é o bot principal: recebe qualquer pedido e encaminha para o agente certo.

Eu uso a Cloudflare e pago o meu domínio nela, então não estou analisando o serviço como um observador neutro. Estou registrando o que configurei na prática no meu próprio endereço.

Resumo rápido

• O que funcionou: cabeçalhos de segurança configurados com CSP restrita, bloqueio de molduras ocultas, trava de câmera e microfone, e notas A+ no Mozilla Observatory e no securityheaders.com.
• Quanto custou: zero reais a mais, já que usei recursos nativos da hospedagem na Cloudflare.
• Quanto tempo levou: cerca de uma noite de testes e ajustes em 3 de outubro de 2026.

Primeiro: o que são cabeçalhos de segurança

Quando você clica em um link, o seu navegador pede a página ao servidor onde o site está guardado. O servidor responde com o conteúdo que você vê na tela, mas antes do texto vem um pacote de dados técnicos invisíveis. Esse pacote é chamado de cabeçalhos de resposta HTTP.

Pense nos cabeçalhos como uma etiqueta de envio colada numa caixa de encomendas. A caixa contém o livro que você comprou, mas a etiqueta traz avisos para a transportadora: “frágil”, “não vire de cabeça para baixo”, “entregar apenas ao destinatário”.

Na internet, os cabeçalhos de segurança funcionam do mesmo jeito. Eles dizem ao navegador: “carregue este texto, mas não permita que ninguém rode scripts vindos de lugares desconhecidos” ou “não deixe nenhuma página desconhecida embutir este site dentro de uma moldura”.

A analogia da etiqueta ajuda a entender, mas tem um limite. A etiqueta de papel depende da boa vontade de quem carrega a caixa. Já no navegador moderno, o software segue as instruções técnicas de forma automática e rígida. Se o cabeçalho diz para barrar, o navegador simplesmente recusa a ação.

O que é CSP (política de segurança de conteúdo)

CSP é a sigla em inglês para Content Security Policy, que traduzimos como Política de Segurança de Conteúdo. É uma regra que cria uma lista rigorosa de onde podem vir os elementos da página, como arquivos de código, imagens e fontes.

Imagine um prédio comercial com controle rígido na portaria. O porteiro tem uma folha com os nomes de quem tem permissão para entrar. Se alguém que não está na lista tentar subir, a entrada é negada no mesmo instante.

O que a CSP faz de verdade: ela declara quais endereços de internet são confiáveis. Se um invasor conseguir enfiar uma linha de código maliciosa no site tentando puxar um script de um servidor estranho, o navegador consulta a regra da CSP, percebe que aquela origem não está autorizada e não baixa o arquivo.

No meu site, a regra diz que tudo deve vir do próprio domínio rodrigoesporto.com. A única exceção que autorizei foi o script do contador de visitas, um detalhe de configuração que ajustei para a etapa seguinte.

O que é a proibição de molduras escondidas

Existe um golpe comum na internet chamado de clickjacking, ou sequestro de clique. O invasor cria uma página enganosa e coloca o site de outra pessoa invisível por cima, dentro de uma moldura transparente (conhecida tecnicamente como iframe). Você acha que está clicando em um botão inofensivo do site falso, mas na prática está clicando em links do site escondido logo abaixo.

Para cortar esse risco pela raiz, o site envia um cabeçalho que proíbe qualquer outro domínio de abrir as páginas do rodrigoesporto.com dentro de molduras.

Pense nisso como um vidro que só pode ser visto de frente, e nunca colocado como fundo falso dentro do espelho de outra loja. Se outro site tentar embutir o meu endereço, o navegador recusa o carregamento da moldura na hora.

O que é o bloqueio de câmera, microfone e localização

O seu navegador tem capacidade de se conectar com a câmera, com o microfone e com o sensor de localização do seu celular ou computador. Sites de videoconferência ou de mapas precisam desses recursos para funcionar.

Um blog pessoal de artigos estáticos não precisa de nada disso. Para evitar qualquer pedido indevido ou abuso de componentes, usei o cabeçalho de política de permissões (Permissions-Policy) para desligar expressamente essas funções.

A instrução diz ao navegador: neste domínio, câmera, microfone e localização estão desativados por padrão. Mesmo que alguém tente inventar uma chamada para esses aparelhos dentro da página, o navegador sabe que a ordem da casa é manter tudo trancado.

O que é a política de referência mais discreta

Quando você está lendo uma página e clica em um link que leva para outro site, o navegador costuma avisar ao site de destino de onde você veio. Essa informação viaja em um campo chamado “referrer” (a página de referência).

Se o endereço original contiver informações longas ou detalhes que não precisam ser espalhados, o outro site acaba registrando isso sem necessidade. A política de referência (Referrer-Policy) permite limitar o que é enviado.

Configurei a regra para que o navegador envie apenas o domínio de origem quando o leitor for para outro endereço seguro, sem expor detalhes extras do caminho da página. É um cuidado simples que preserva a discrição de quem navega.

Os testes no Mozilla Observatory e no securityheaders.com

Depois de ajustar esses avisos no servidor, você precisa testar para ter certeza de que o navegador realmente está recebendo as instruções corretas. Não adianta confiar apenas no que a gente acha que configurou.

Usei duas ferramentas públicas muito conhecidas no setor:

1. O securityheaders.com, criado pelo pesquisador Scott Helme, que analisa os cabeçalhos de resposta HTTP e dá uma nota de A+ até F.
2. O Mozilla Observatory, desenvolvido pela fundação Mozilla (a mesma organização por trás do navegador Firefox), que audita as práticas de segurança e também emite uma nota de conformidade.

O site rodrigoesporto.com recebeu a nota máxima, A+, em ambos os serviços na revisão de segurança feita em 3 de outubro de 2026.

Essas notas não foram inventadas por mim nem declaradas pela hospedagem. Elas foram medidas de fora por verificadores públicos e independentes. Quem acompanha essas medições na rotina do time é o agente Segurança: confere todo dia, de fora, se o site continua seguro, sem mexer em nada.

O que eu usei

• O painel da Cloudflare para configurar os cabeçalhos de resposta HTTP nas páginas publicadas.
• O domínio rodrigoesporto.com, já ativo e com certificado seguro.
• O Darth, bot principal do time, acompanhando as checagens enquanto eu aplicava as mudanças.
• O agente Segurança, responsável por rodar as conferências diárias externas.
• As ferramentas de auditoria online do Mozilla Observatory e do securityheaders.com.

Não usei nenhum plugin pago ou serviço adicional. Tudo foi feito com recursos já disponíveis na plataforma onde o site roda.

Como foi

Se você quiser aplicar essa mesma proteção no seu site, este é o caminho geral:

1. Mapeie quais recursos o seu site realmente precisa carregar. Para um site simples de textos, quase tudo deve vir da sua própria hospedagem.
2. Escreva as regras da sua política de conteúdo (CSP), liberando apenas o seu domínio e eventuais serviços externos indispensáveis.
3. Configure a proibição de molduras externas para impedir que o seu site seja colocado dentro de páginas de terceiros.
4. Desative permissões desnecessárias como microfone, câmera e geolocalização.
5. Ajuste a política de referência para não vazar caminhos completos a outros servidores.
6. Salve essas configurações no serviço de borda ou no servidor que entrega as páginas.
7. Abra o site no navegador comum e confira se todo o texto, fontes e imagens continuam abrindo sem falhas.
8. No securityheaders.com, digite o endereço do site e inicie a checagem. O relatório confirma a nota A+ em destaque verde no topo.
9. No Mozilla Observatory, digite o domínio e rode a análise completa. A ferramenta exibe a nota A+ e o detalhamento de cada teste aprovado.

O que deu errado ou o que aprendi

A maior lição que tirei dessa etapa é que você não precisa adivinhar quais regras criar nem tentar decorar códigos difíceis.

Quando você roda um teste no securityheaders.com ou no Mozilla Observatory, eles não dão apenas uma nota seca. Eles mostram cada item que foi analisado, explicam em termos simples para que serve aquele cabeçalho e indicam exatamente o valor que você deve preencher.

Eu aprendi que segurança bem planejada trabalha em silêncio. Ela não cria barreiras chatas para o leitor, não pede que ninguém preencha desafios visuais e não deixa a página pesada. O site continua abrindo rápido, e quem está lendo nem nota que o navegador acabou de receber uma lista completa de proteção.

Nenhuma dessas ferramentas substitui julgamento. Elas encurtam o caminho entre “eu sei o que quero” e “está no ar”.

Custos e limites

Em dinheiro, essa etapa custou zero reais a mais. Eu usei recursos nativos de cabeçalhos que já fazem parte da minha estrutura de hospedagem e utilizei serviços de teste que são gratuitos e abertos para qualquer pessoa na internet.

Também é importante deixar os limites claros:

• Uma nota A+ no securityheaders.com ou no Mozilla Observatory significa que as instruções de segurança do servidor estão muito bem configuradas. Isso não significa que o site seja invulnerável a qualquer outro tipo de problema no futuro.
• Os cabeçalhos de segurança orientam navegadores modernos. Se um visitante usar um navegador extremamente antigo que não entende esses comandos, algumas dessas proteções não serão aplicadas por aquele programa.
• Essas regras não impedem que alguém copie textos públicos da página. A função delas é evitar abusos técnicos de execução de código e sequestro de cliques.

Eu uso a Cloudflare e pago o domínio nela. As notas A+ vieram de verificações externas no Mozilla Observatory e no securityheaders.com, e não de um anúncio comercial da empresa que hospeda o site.

O que eu faria diferente

Se eu estivesse começando hoje, teria rodado o securityheaders.com logo no primeiro teste do site, antes mesmo de considerar a estrutura pronta.

Como o teste é gratuito e roda em poucos segundos, ele funciona como um roteiro prático do que falta ajustar. Deixar para a revisão final funciona, mas fazer a checagem cedo ajuda a entender o comportamento do navegador logo nos primeiros passos.

Para quem serve e para quem não serve

Serve para qualquer pessoa que administra um site próprio e quer oferecer uma navegação protegida para os seus visitantes, sem precisar gastar dinheiro extra nem instalar dezenas de complementos pesados.

Não serve como substituto para auditorias de sistemas corporativos complexos, que envolvem bancos de dados sigilosos ou processamento de pagamentos. Nesses ambientes com dezenas de integrações bancárias, a configuração de segurança exige análises mais amplas.

Também não serve para quem espera que os agentes façam tudo sozinhos sem supervisão humana: eu fiz as configurações no painel, o Darth acompanhou de fora e o agente Segurança faz as rondas diárias sem tocar nos arquivos.

Fechamento

Configurar cabeçalhos de resposta e uma política de segurança de conteúdo fecha portas importantes para fraudes sem atrapalhar a leitura. O site rodrigoesporto.com conquistou nota A+ tanto no Mozilla Observatory quanto no securityheaders.com, provando que um site pessoal simples pode ter o mesmo rigor de segurança de grandes portais.

Se você tem um site no ar, faça o teste gratuito no securityheaders.com e no Mozilla Observatory para ver como estão as suas notas hoje. Se quiser trocar ideias sobre essas configurações ou acompanhar as próximas etapas da série, estou no X: @RodrigoesPorto.

Na próxima parte eu conto como passei a contar as visitas do site sem usar cookies.

Fontes e links

• Mozilla Observatory: https://developer.mozilla.org/en-US/observatory
• Security Headers: https://securityheaders.com
• Revisão de segurança do agente Segurança, 3 de outubro de 2026