# Security.txt no WordPress: O arquivo em 5 passos 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.

Campos do security.txt segundo o RFC 9116
Campo	Obrigatório	Para que serve
Contact	Sim	E-mail, formulário ou URL para reportar a falha.
Expires	Sim	Data de validade ISO 8601 do arquivo.
Encryption	Não	Link para a chave PGP de criptografia do reporte.
Policy	Não	URL da política de divulgação responsável.
Acknowledgments	Não	Página que credita quem já reportou falhas.
Canonical	Não	URL canônica do próprio security.txt.

## 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:seguranca@seudominio.com 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

É possível publicar o security.txt no WordPress sem instalar plugin?

Sim. Você cria a pasta .well-known na raiz pública do site via SFTP e salva o arquivo security.txt dentro dela, sem nenhum plugin. O único cuidado extra é liberar o caminho /.well-known/ no .htaccess para o WordPress não devolver 404. Esse método físico tende a ser mais confiável que o plugin, porque não depende do template do tema, que é o que costuma quebrar o Content-Type text/plain exigido pelo RFC 9116.

Por que o WordPress devolve 404 no caminho /.well-known/security.txt?

Porque as rewrite rules do permalink interceptam o caminho antes de o servidor entregar o arquivo físico. O WordPress trata quase toda URL como um post ou página, e /.well-known/security.txt não existe como conteúdo do site. A correção é adicionar uma exceção no .htaccess, antes do bloco do WordPress, que entrega o arquivo direto. Sem essa regra, o arquivo existe no disco mas o caminho canônico do RFC 9116 retorna 404.

Qual a diferença entre o security.txt e o robots.txt?

O robots.txt instrui crawlers sobre o que rastrear; o security.txt instrui pesquisadores sobre como reportar uma vulnerabilidade. São arquivos de texto puro em caminhos fixos, mas com públicos opostos: um fala com máquinas de indexação, o outro com pessoas que encontram falhas. O security.txt fica em /.well-known/security.txt, enquanto o robots.txt fica na raiz. Nenhum dos dois protege o site sozinho; ambos padronizam comunicação.

Quanto tempo leva para configurar o security.txt num site WordPress?

Cerca de 10 minutos pelo método físico: criar a pasta, salvar o arquivo, ajustar o .htaccess e validar. O campo Expires deve ter data futura, em geral um ano à frente, com renovação agendada. O que costuma estender esse tempo é o ajuste do Content-Type para text/plain, que pode exigir uma regra extra de cabeçalho no servidor quando o tema captura a requisição.

O que acontece se o campo Expires do security.txt vencer?

Ferramentas de varredura como as da OWASP e validadores externos passam a tratar o arquivo como abandonado e ignoram o contato informado. Na prática, o canal de aviso deixa de funcionar mesmo com o arquivo no ar. Por isso o RFC 9116 torna o campo Expires obrigatório: ele força a manutenção periódica. Defina uma data um ano à frente e inclua a renovação na sua rotina de auditoria de segurança.

--- ## 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.