O que os sites esquecem: 30% sem nenhum cabeçalho seguro

A segurança de um site muitas vezes depende de pequenas configurações que ninguém chegou a ativar: um cabeçalho ausente, um domínio de e-mail sem proteção, um plugin que não é atualizado há um ano. Analisamos o que 215 sites verificados pelo nosso scanner gratuito PromoPilot Shield têm em comum, e o quadro é mais comum, e mais fácil de corrigir, do que se poderia imaginar.

Dados: verificações de 16.07 a 06.11.2026, atualizado em 06.11.2026

Sobre a amostra

São 215 sites únicos que seus donos ou especialistas enviaram ao Shield entre 16 de julho e 6 de novembro de 2026. A amostra não é aleatória, então tudo abaixo descreve a nossa amostra, não a internet como um todo. Os detalhes estão na seção «Metodologia», no final.

Cabeçalhos de segurança: a proteção mais barata que os sites ignoram

Cabeçalhos de segurança são instruções curtas que o servidor envia ao navegador junto com cada página. Não custam nada e costumam exigir uma linha de configuração cada. Veja o que fazem os seis que verificamos:

• Strict-Transport-Security (HSTS) diz aos navegadores para usar sempre HTTPS no seu domínio, o que ajuda a evitar ataques de rebaixamento de protocolo.
• Content-Security-Policy (CSP) lista as origens das quais uma página pode carregar scripts e limita o estrago de um código injetado.
• X-Frame-Options impede que outros sites incorporem suas páginas em um quadro oculto (clickjacking).
• X-Content-Type-Options proíbe os navegadores de adivinhar o tipo de arquivo, o que fecha um caminho para scripts disfarçados.
• Referrer-Policy controla quanto do endereço da sua página é repassado a outros sites.
• Permissions-Policy desativa recursos do navegador, como câmera ou geolocalização, de que suas páginas não precisam.

Os cabeçalhos ausentes tendem a vir em conjunto. O resultado individual mais comum foi não ter nenhum dos seis: 65 sites. O segundo mais comum foi ter os seis: 38 sites. No meio, 22 sites não têm um, 26 não têm dois, 13 não têm três, 15 não têm quatro e 36 não têm cinco. Em outras palavras, os sites raramente adicionam cabeçalhos um a um: ou têm uma configuração pensada, ou não têm nada.

O HSTS é o mais difundido dos seis e ainda assim falta em 46% dos sites (99 de 215). O Content-Security-Policy é o mais difícil de acertar, então seus 65% (140 de 215) são compreensíveis, mas os cabeçalhos mais simples não têm essa desculpa.

E-mail: quem pode enviar mensagens em seu nome

Os registros de e-mail ficam no DNS, não no site, e por isso são tão esquecidos. O SPF lista os servidores autorizados a enviar e-mail do seu domínio. O DMARC diz aos servidores receptores o que fazer com mensagens que não passam na verificação. Sem os dois, qualquer pessoa pode enviar um e-mail que parece ter vindo de você.

Na nossa amostra, 49% dos domínios (105 de 215) não tinham registro DMARC. Outros 33% (71) o tinham em p=none, que só coleta relatórios e não bloqueia nada. Isso dá 82% (176 de 215) sem DMARC rigoroso (DMARC rigoroso: p=quarantine ou p=reject). O SPF estava ausente em 28% (60 de 215). Para uma empresa, as consequências são concretas: faturas falsas ou e-mails de redefinição de senha chegando aos seus clientes com o nome do seu domínio, e seus e-mails reais caindo com mais frequência no spam.

Outros dois registros estavam ausentes quase em toda parte: CAA (93%, 200 de 215) e MTA-STS (71%, 152 de 215). O CAA limita quais autoridades podem emitir certificados para o seu domínio; o MTA-STS exige entrega criptografada do e-mail recebido. Vale ter os dois, mas o risco é baixo para um site pequeno típico. Corrigiríamos o DMARC muito antes de qualquer um deles.

WordPress contra o resto

Os sites WordPress da nossa amostra (n=50) são visivelmente diferentes dos outros 165 sites.

Isso não é um veredito sobre o WordPress em si. É o CMS mais popular do mundo e, por isso, também a mais estudada: o banco aberto de vulnerabilidades do WordPress em que nosso scanner se baseia reúne 1 797 entradas de plugins e 84 de temas. As coincidências vêm de versões desatualizadas de plugins, temas e núcleo. Uma ressalva sobre os 4%: o scanner tem um banco de vulnerabilidades detalhado para plugins e temas do WordPress, enquanto nas outras plataformas verifica principalmente bibliotecas JavaScript e software de servidor, então a diferença reflete em parte o que conseguimos enxergar, e não só o quanto cada plataforma é segura.

Tenha em mente o que «componente vulnerável» significa aqui: a versão instalada cai em uma faixa listada no banco de dados. Não testamos se a falha pode de fato ser explorada naquele site.

Cookies e divulgação de versões

Cookies e banners de servidor são pequenos detalhes que ajudam um atacante a se preparar. Entre os 215 sites:

• 21% (45) definem cookies sem HttpOnly, então scripts da página podem lê-los;
• 16% (35) definem cookies sem Secure, então eles podem trafegar por HTTP aberto;
• 19% (40) definem cookies sem SameSite, o que enfraquece a proteção contra requisições entre sites;
• 17% (36) enviam um cabeçalho X-Powered-By com versão, e 11% (24) mostram a versão do servidor em um cabeçalho;
• 6% (13) não redirecionam visitantes de HTTP para HTTPS.

Nenhum desses pontos é uma invasão por si só. Juntos, poupam tempo do atacante, e levam minutos para ser fechados.

Um checklist de 30 minutos

1. Adicione agora cinco cabeçalhos, CSP separadamente (próximo passo). Exemplo para Nginx (dentro do bloco server):

   add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
   add_header X-Frame-Options "SAMEORIGIN" always;
   add_header X-Content-Type-Options "nosniff" always;
   add_header Referrer-Policy "strict-origin-when-cross-origin" always;
   add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

   Apache (.htaccess):

   Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
   Header always set X-Frame-Options "SAMEORIGIN"
   Header always set X-Content-Type-Options "nosniff"
   Header always set Referrer-Policy "strict-origin-when-cross-origin"
   Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"

   Adicione o Content-Security-Policy por último, primeiro como Content-Security-Policy-Report-Only, porque ele pode quebrar scripts dos quais você depende.
2. Publique um registro SPF que liste apenas os serviços que realmente enviam o seu e-mail.
3. Publique o DMARC. Comece com p=none e um endereço para relatórios, leia os relatórios por algumas semanas, depois passe para quarantine e, por fim, para reject.
4. Atualize plugins, temas e o núcleo, e apague tudo o que você não usa.
5. Oculte a versão do CMS e remova o X-Powered-By (expose_php = Off remove o X-Powered-By do PHP, server_tokens off oculta a versão do Nginx).
6. Defina HttpOnly, Secure e SameSite nos cookies de sessão.
7. Redirecione todo o tráfego HTTP para HTTPS com um redirecionamento permanente.

Teste o resultado após cada mudança, pois um cabeçalho errado pode quebrar conteúdo incorporado, widgets de pagamento ou analytics.

Verifique o seu próprio site

Você pode ver como está o seu site com uma verificação gratuita no PromoPilot Shield (promopilot.link/pt/security/). É uma checagem passiva e um ponto de partida, não uma proteção por si só: corrigir o que ela encontrar continua sendo com você.

Metodologia

• Fonte: verificações do scanner gratuito PromoPilot Shield de 16.07.2026 a 06.11.2026. O scanner é passivo: lê respostas do servidor, DNS e o HTML da página inicial e de um conjunto limitado de URLs, sem tentativas de invasão.
• Unidade: um site (host sem www), com a sua última verificação bem-sucedida. De 285 execuções, 272 tiveram sucesso e 218 eram sites únicos; excluímos 3 (contas de teste e sites do PromoPilot), restando 215.
• Plataforma: detectada por indícios nas respostas (generator, caminhos, cabeçalhos): WordPress 50, Next.js 10, Shopify 7, Joomla, Wix e OpenCart 3 cada; em 139 a plataforma não foi detectada ou é própria. Comparamos apenas o WordPress (n=50) com todos os demais (n=165), pois os outros grupos têm menos de 20 sites.
• Componente vulnerável: a versão do plugin, tema ou núcleo coincide com uma faixa do banco aberto de vulnerabilidades do WordPress (1 797 entradas de plugins e 84 de temas no nosso feed em 06.11.2026). É uma coincidência de versão; a exploração não foi testada.
• Seis cabeçalhos: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, contados como ausentes na página inicial.
• E-mail: SPF e DMARC lidos do DNS do domínio. «DMARC fraco» significa p=none ou um registro sem política.
• Notas: a escala do Shield de A+ a E e uma pontuação de 0 a 100 ponderam os achados pelo nível de risco.
• Limitações: a amostra não é aleatória: são sites que donos ou especialistas escolheram enviar (autosseleção). Os números descrevem esta amostra, não toda a internet. Por país: .com 84, .ua 24, os demais com menos de 20, por isso não comparamos países. Não publicamos domínios, apenas agregados de grupos de 20 sites ou mais.

FAQ

Quais cabeçalhos de segurança são essenciais?

Não existe uma lista obrigatória única, mas seis cabeçalhos cobrem o básico: Strict-Transport-Security (HSTS), Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy e Permissions-Policy. HSTS e X-Content-Type-Options são os mais fáceis de adicionar e raramente quebram algo. O Content-Security-Policy é o mais poderoso, mas exige testes, então comece em modo report-only.

Por que a falta de um registro DMARC é perigosa?

Sem DMARC, os servidores de e-mail receptores não têm instrução sobre o que fazer com mensagens que dizem falsamente vir do seu domínio. Atacantes podem enviar aos seus clientes e-mails de phishing que parecem ser seus. Na nossa amostra, 49% dos domínios (105 de 215) não tinham registro DMARC e outros 33% (71) tinham p=none, que apenas monitora e não bloqueia nada.

O WordPress é inseguro por si só?

Não. Na nossa amostra, a diferença está ligada às versões de plugins, temas e núcleo, não à plataforma em si. A versão de um plugin, tema ou núcleo coincidiu com uma vulnerabilidade conhecida em 30% dos sites WordPress (15 de 50), contra 4% dos demais sites (7 de 165). Atualizar e remover plugins sem uso elimina essas coincidências. Parte da diferença vem de o banco de dados do WordPress ser mais detalhado.

Como posso verificar o meu próprio site?

Faça uma verificação gratuita no PromoPilot Shield: ele lê de forma passiva as respostas do seu servidor, os registros DNS e o HTML da página inicial, e mostra quais cabeçalhos e registros de e-mail estão ausentes e o que está sendo revelado sem necessidade. Você também pode inspecionar cabeçalhos com as ferramentas de desenvolvedor do navegador ou com curl -I, e checar SPF e DMARC em qualquer ferramenta de consulta DNS.

Sites pequenos precisam de CAA e MTA-STS?

Em geral, são de baixa prioridade. O CAA estava ausente em 93% dos sites (200 de 215) e o MTA-STS em 71% (152 de 215), mas o risco prático é baixo em comparação com a falta de DMARC, plugins desatualizados ou ausência de HSTS. Adicione-os quando o básico estiver resolvido, principalmente se você lida com e-mail sensível ou pagamentos.

Como citar

PromoPilot (2026). O que os sites esquecem: configurações de segurança em 215 verificações do Shield. Dados 16.07–06.11.2026. CC BY 4.0: https://promopilot.link/uploads/blog/research/site-security-0711/site-security-settings-2026-11-06.csv . Artigo: https://promopilot.link/pt/blog/o-que-os-sites-esquecem-configuracoes-de-seguranca-215-verificacoes

Baixar os dados

A tabela agregada (CSV, licença CC BY 4.0): https://promopilot.link/uploads/blog/research/site-security-0711/site-security-settings-2026-11-06.csv. Contém apenas percentuais, sem domínios.