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.txt.
Validar o formato de um security.txt
Um security.txt é o arquivo de texto com que um site indica a quem tenha achado uma vulnerabilidade a quem se dirigir, e o seu formato é fixado pela RFC 9116. Cole o seu conteúdo e esta ferramenta verifica a sintaxe, confirmando que campos obrigatórios como `Contact` e `Expires` estão presentes e que os seus valores tomam a forma devida.
**O que costuma passar despercebido aqui é o tratamento de `Expires`.** Não só é um campo obrigatório, como **um arquivo cujo momento declarado já passou é tido por não válido.** Publique-o e desentenda-se, e ao cabo de alguns anos ele seguirá ali mas inerte, de modo que convém geri-lo junto com um plano de renovação. **Sua localização também é fixa: cabe-lhe `/.well-known/security.txt`.** Quando o arquivo vai assinado, o campo `Canonical` declara a URL autorizada para que o leitor possa certificar-se de que ninguém o manipulou.
Como se usa
- Cole o conteúdo do seu security.txt Insira o arquivo inteiro tal como está.
- Experimente antes os exemplos São oferecidos tanto um exemplo válido quanto outro com erros.
- Leia os pontos apontados **São relatados os campos obrigatórios ausentes e os valores mal formados.**
- Confira o momento indicado em `Expires` **Confirme que não fica no passado e decida de antemão quando o renovará.**
Dicas para aproveitar melhor
- O local oficial do security.txt é
/.well-known/security.txt. 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.
Quando é útil
Tornar explícito o seu contato de segurança
Quem achar algo não terá de caçar um endereço, com o que o aviso chegará bem mais facilmente.
Revisar o que você publicou
**Um arquivo mal formado não dá sinal externo algum, então só a validação o revela.**
Prevenir a expiração
Você pode conferir de tempos em tempos que `Expires` não venceu.
Manter um padrão na organização
Quando se gerem vários sites, você pode confirmar que todos seguem o mesmo formato.
Termos de security.txt
- Contact
- Campo **obrigatório** que dá um meio de contato: um endereço de correio, um telefone ou a URL de um formulário de aviso.
- Expires
- Campo **obrigatório** após cujo momento declarado o arquivo é tido por não válido.
- Encryption
- Aponta uma chave pública com a qual um aviso pode ser cifrado.
- Policy
- A URL de uma página que expõe a política sobre divulgação de vulnerabilidades.
- Canonical
- A URL autorizada em que este arquivo há de residir. **É aquilo com que uma assinatura é cotejada.**
- Preferred-Languages
- Declara os idiomas em que os avisos podem ser recebidos, separados por vírgulas como em `en, ja`.
Perguntas frequentes
https://example.com/.well-known/security.txt 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.mailto:[email protected]. Sem o esquema, analisadores automáticos podem não reconhecê-lo corretamente.
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.txt, 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.