Publicar o arquivo de divulgação de falhas chamado security.txt diz a pesquisadores como reportar uma vulnerabilidade no seu site. Segundo o RFC 9116 (2022), ele fica em /.well-known/security.txt e é servido como text/plain. No WordPress, esse caminho exige cuidado com rewrite rules. Publique-o em minutos.

O security.txt é um arquivo de texto simples que informa a quem encontra uma vulnerabilidade no seu site para onde mandar o aviso. Ele não bloqueia nenhum ataque: a função dele é encurtar o tempo entre um pesquisador descobrir a falha e você ficar sabendo. No WordPress, publicar o security.txt tem uma pegadinha que a maioria dos tutoriais ignora, porque o próprio CMS intercepta o caminho /.well-known/ via rewrite rules. Quem cuida de segurança a sério trata esse arquivo como parte dos conteúdos de segurança WordPress da FULL, junto com firewall e hardening. Este guia mostra os 5 passos para fazer certo.

Primeiros passos: O que é o security.txt e por que ele importa

O security.txt virou padrão oficial em abril de 2022 com o RFC 9116, depois de 5 anos como proposta. Ele resolve um problema concreto: quando alguém de fora acha uma falha no seu site, essa pessoa não sabe para qual e-mail escrever, desiste ou publica a falha sem aviso.

O arquivo padroniza esse contato num lugar previsível, lido por humanos e por ferramentas como WPScan e OWASP. A lógica é a mesma do robots.txt, mas voltada à divulgação responsável de vulnerabilidades: o leitor encontra o arquivo num caminho fixo, lê os campos em texto puro e age. Para um site que já investe em cabeçalhos de segurança HTTP, o security.txt fecha o ciclo de comunicação. A gente vê no suporte da FULL que sites com canal de contato claro recebem o aviso antes de a falha virar incidente público, e não depois.

Onde o arquivo security.txt deve ficar e quais campos usar

Segundo o RFC 9116, o security.txt deve ficar em https://seudominio.com/.well-known/security.txt, servido como text/plain e por HTTPS. Dois campos são obrigatórios: Contact (e-mail, formulário ou URL para reporte) e Expires (a data de validade, no formato ISO 8601). Sem esses dois, o arquivo é inválido para os validadores.

Os campos opcionais agregam contexto, mas o que faz o security.txt funcionar de fato são Contact e Expires bem preenchidos. Use sempre uma data de Expires futura e renove antes do vencimento, porque ferramentas tratam um arquivo vencido como abandonado.

Passo a passo: Como publicar o security.txt no WordPress

Publicar o security.txt no WordPress leva cerca de 10 minutos e tem dois caminhos: arquivo físico no servidor ou geração via plugin. Em testes na base FULL, o caminho físico tende a ser mais confiável porque não depende do template do tema, que é justamente o que costuma quebrar o Content-Type. Siga os cinco passos abaixo na ordem.

Passo 1: Escreva o conteúdo do arquivo

Crie um arquivo de texto puro com os campos mínimos. Um exemplo válido tem este formato:

Contact: mailto:[email protected]
Expires: 2027-06-10T00:00:00.000Z
Policy: https://seudominio.com/politica-de-seguranca
Preferred-Languages: pt, en

Use um e-mail real e monitorado no campo Contact. A data de Expires deve ser futura, em geral um ano à frente.

Passo 2: Crie a pasta .well-known no servidor

Acesse o servidor por SFTP ou pelo gerenciador de arquivos da hospedagem e crie a pasta .well-known na raiz pública do site, no mesmo nível do wp-config.php e do index.php. Dentro dela, salve o arquivo como security.txt. O nome da pasta começa com ponto, então habilite a exibição de arquivos ocultos no seu cliente FTP.

Passo 3: Libere o caminho no .htaccess do WordPress

Em servidores Apache, adicione uma regra que impede o WordPress de capturar o caminho /.well-known/ antes que o arquivo seja servido. No topo do .htaccess, antes do bloco do WordPress, inclua uma exceção que entrega o arquivo físico direto. Sem isso, as rewrite rules do permalink interceptam a URL e devolvem 404 no caminho canônico.

Passo 4: Confirme o content-type text/plain

Abra https://seudominio.com/.well-known/security.txt no navegador e verifique o cabeçalho de resposta. O Content-Type precisa ser text/plain, não text/HTML. Se vier como HTML, o arquivo passou pelo tema e os validadores vão rejeitá-lo. Force o tipo correto com uma regra de cabeçalho no servidor.

Passo 5: Valide o arquivo num leitor externo

Use um validador de security.txt externo para confirmar que os campos obrigatórios estão presentes e a data de Expires é futura. Documente o arquivo no seu fluxo de auditoria de segurança do WordPress para renová-lo antes do vencimento.

Os erros mais comuns ao configurar o security.txt

Boa parte dos chamados sobre security.txt no suporte da FULL não são sobre criar o arquivo, e sim sobre o WordPress devolver o conteúdo errado. O erro clássico é o arquivo ser servido como text/HTML porque passou pelo template do tema: o validador descarta tudo por não ser text/plain, e a denúncia nunca chega.

O segundo erro mais frequente é a colisão de rewrite rules. Arquivo colocado na raiz pública mais um permalink que captura /.well-known/ resulta em WordPress devolvendo 404 no caminho exigido pelo RFC 9116, mesmo com o arquivo existindo fisicamente. O terceiro é o campo Expires com data passada: ferramentas de varredura tratam o security.txt como abandonado e ignoram o contato. Na maioria dos cenários testados, resolver o Content-Type e a regra do .htaccess já deixa o arquivo válido.

Por que o security.txt encurta a resposta a cves reais

O arquivo security.txt não corrige falha nenhuma, mas encurta o tempo de resposta a CVEs reais nos plugins do site. Segundo o perfil público do WPVulnerability, o Contact Form 7 já acumulou 12 CVEs ao longo dos anos, com destaque para o CVE-2020-35489, de CVSS 10.0.

Essa falha permitia upload irrestrito de arquivos e foi corrigida na versão 5.3.2. Todas já estão corrigidas, sinal de manutenção ativa, e não de risco atual. O All in One Security mostra o outro lado: registrou o CVE-2026-8438, CVSS 7.2, em versões abaixo da 5.4.8, com patch disponível. Quando um pesquisador acha algo novo no seu site, o security.txt diz a ele para onde escrever. A FULL é a única empresa brasileira CNA (CVE Numbering Authority) sob a CISA desde maio de 2022, autorizada a atribuir IDs CVE oficiais, então quem documenta vulnerabilidade aqui literalmente cataloga CVE.

O cenário de ameaça que justifica o canal de contato

A maior parte dos ataques contra sites hoje é automatizada, o que torna o canal de aviso humano ainda mais valioso. Segundo o Cloudflare Radar, nos dados de junho de 2026 no Brasil, os ataques de camada de aplicação mitigados se dividem em 82,4% por DDoS e 16,4% por firewall de aplicação (WAF).

Esse volume justifica manter o WAF ativo e, em paralelo, ter um canal claro para o que escapa do bloqueio automático. A gente vê no suporte da FULL que a defesa funciona em camadas: o WAF barra o tráfego malicioso em execução, o hardening reduz a superfície e o security.txt encurta o aviso quando alguém de fora acha a falha primeiro. Para ver como o firewall encaixa nesse fluxo, o tutorial do All in One Security detalha o WAF embarcado, que cobre o que o security.txt não cobre. Pesquisadores também leem o robots.txt no mesmo contexto, como mostra nosso guia sobre crawlers de IA no robots.txt.

Acelere a segurança do site com o bundle da FULL

Configurar o security.txt é só uma camada; manter firewall, 2FA e plugins atualizados em todos os seus sites é o que sustenta a segurança no dia a dia. No plano PRO da FULL, você ativa o All in One Security e os outros 16 plugins premium em quantos sites quiser por R$849 por mês.

Quem gerencia 10 sites paga o equivalente a R$85 por site, com o firewall, a varredura e o hardening centralizados num só painel. Ative tudo em FULL.services/planos e pare de configurar segurança site por site na mão.

Perguntas frequentes sobre o security.txt

Próximos passos para fechar o canal de segurança

Depois de publicar o security.txt, o trabalho é de manutenção: renove o campo Expires antes do vencimento e revise o arquivo a cada auditoria. O security.txt é barato de manter e paga caro no dia em que um pesquisador encontra uma falha antes de um invasor. Combine-o com firewall, 2FA e atualização disciplinada de plugins para cobrir as camadas que o arquivo de contato não alcança. Para continuar aprendendo, o FULL Academy reúne os tutoriais e guias de segurança WordPress num só lugar.