Validador de security.txt

Cole o conteúdo do seu security.txt (RFC 9116) para detectar erros de sintaxe. Verifica campos obrigatórios como Contact e Expires e o formato dos seus valores, confirmando se está publicado corretamente em /.well-known/security-text.

Dicas

  • O local oficial do security.txt é /.well-known/security-text. Por compatibilidade, vale publicar também uma cópia em /security.txt (na raiz do site).
  • Escreva Contact como uma URI com esquema, como mailto:, https: ou tel:. Um endereço de e-mail sem esquema não segue a RFC 9116 e pode não ser reconhecido por analisadores automáticos.
  • Defina Expires para no máximo um ano à frente e prorrogue-o a cada renovação. Um arquivo expirado corre o risco de ser tratado como um contato abandonado.
  • Toda a validação desta ferramenta ocorre inteiramente no seu navegador — nada do que você cola é enviado a qualquer servidor, então é seguro conferir um arquivo antes de publicá-lo.

Perguntas frequentes

A RFC 9116 especifica https://example.com/.well-known/security-text como o local oficial. Como muitas implementações também verificam o caminho legado https://example.com/security.txt, recomenda-se publicá-lo nos dois lugares por compatibilidade.

O arquivo não é invalidado automaticamente, mas pesquisadores de segurança e ferramentas automatizadas o tratarão como informação desatualizada e sem manutenção, reduzindo sua confiabilidade. Recomenda-se estender a data pelo menos uma vez por ano.

Não, são coisas diferentes. O security.txt é um arquivo de contato que indica a quem recorrer e como; ele não define se existe recompensa financeira nem seu valor. Ainda assim, é possível linkar uma página de recompensas pelo campo Policy ou Hiring.

Você pode escrevê-lo, mas a RFC 9116 define Contact como uma URI, então é preciso incluir um esquema, como mailto:[email protected]. Sem o esquema, analisadores automáticos podem não reconhecê-lo corretamente.

Não é obrigatório, mas a RFC 9116 lista uma assinatura OpenPGP como recomendação. Ao assinar, os pesquisadores conseguem verificar que o conteúdo do arquivo não foi adulterado por terceiros.
ツールくん

Curiosidade — A origem do security.txt — o "primeiro ponto de contato" que só um programa de recompensas por falhas não conseguia oferecer

O security.txt foi proposto em 2017 pelos pesquisadores de segurança Ed Overflow e Kagan Baytas. Naquela época, quem descobria uma vulnerabilidade muitas vezes não tinha um caminho claro para relatá-la, acabando limitado a um formulário de contato genérico ou uma mensagem direta em redes sociais. Os relatos costumavam demorar para chegar à pessoa certa, ou eram simplesmente ignorados.

A proposta foi levada ao IETF (Internet Engineering Task Force) e, depois de anos de discussão e revisão, tornou-se o padrão oficial RFC 9116 em 2022. O mecanismo é simples: o operador do site publica um único arquivo de texto em /.well-known/security-text, e os pesquisadores conseguem determinar mecanicamente quem contatar, em que idioma e sob qual política.

Grandes empresas de tecnologia como GitHub, Google, Facebook e LinkedIn adotaram o security.txt, sendo comum ver um link para um programa de divulgação de vulnerabilidades ou recompensas por falhas por meio do campo Policy. Ele funciona como uma verdadeira "porta de entrada" que alcança pesquisadores que talvez nunca encontrassem sozinhos uma plataforma de recompensas.

Como extensão natural da RFC 9116, cada vez mais organizações vinculam documentos CSAF (Common Security Advisory Framework) pelo campo CSAF, padronizando a troca de avisos de vulnerabilidade. O security.txt deixou de ser apenas um arquivo de contato e vem se tornando a porta de entrada para todo o processo de resposta de segurança de uma organização.