Gerador e validador de security.txt

O que é security.txt

Um arquivo security.txt é um arquivo de texto curto que diz a quem encontrou uma vulnerabilidade no seu site para onde avisar. Antes de ele existir, o pesquisador que percebia algo errado tinha que adivinhar: tentar security@ e torcer para alguém ler, vasculhar uma página de contato, ou desistir e ficar calado. O arquivo troca esse chute por um lugar fixo e um punhado de campos nomeados, e virou padrão — o RFC 9116 — em abril de 2022.

O formato é propositalmente simples. Cada linha é um nome de campo, dois-pontos, um espaço e um valor, e linhas começadas por # são comentários. Só dois campos são obrigatórios: Contact, que diz para onde mandar os relatos, e Expires, que diz a partir de quando a informação deixa de valer. Todo o resto — o link da sua política, uma chave de criptografia, uma página de agradecimentos, os idiomas que você lê — é opcional.

Ele também é pequeno o bastante para dar errado sem ninguém notar, e é para isso que serve o conferidor desta página. Dos arquivos publicados pelos 500 domínios de maior tráfego da web, menos da metade cumpre hoje o padrão com que foram escritos.

Como usar

1. Informe o contato e a validade. Contact precisa ser um URI, então um e-mail leva o prefixo mailto: e um telefone leva tel:. O campo de validade já vem preenchido com um ano à frente, que é o máximo recomendado pelo padrão.
2. Acrescente os campos opcionais que precisar. Um link de política, uma chave OpenPGP, uma página de agradecimentos, os idiomas que você lê. Contact e quase todos os outros podem se repetir; Expires e Preferred-Languages, não.
3. Publique, ou confira o que você já serve. O arquivo fica em /.well-known/security.txt por HTTPS. Vá para a aba de conferência para colar um arquivo existente e ver cada problema com o número da linha.

Onde os arquivos publicados erram

Os números vêm de pedir as duas localizações possíveis aos 500 domínios de maior tráfego da web pelo ranking Tranco e passar tudo o que voltou pelo mesmo conferidor que esta página oferece. 115 desses domínios publicam alguma coisa; 45 deles, 39,1%, não têm nenhum erro.

O defeito mais comum de longe é a falta do campo Expires: 48 arquivos, 41,7% de tudo o que é publicado. Não é uma regra obscura — Expires é um dos dois únicos campos obrigatórios — e há uma explicação limpa. Expires não existia nos primeiros rascunhos a partir dos quais todo mundo implementou; foi acrescentado no caminho até virar RFC. Ou seja, o problema mais frequente é o campo que o padrão acrescentou por último, em arquivos que estavam certos quando foram escritos.

A validade falha de um segundo jeito: 11 desses arquivos declaram que já venceram, o que pela própria definição do padrão significa que o conteúdo não deve mais ser usado. O de uma rede social muito conhecida trazia uma data de janeiro de 2024. Outros treze empurram a data tão longe que ela nunca vence de forma útil: o de um grande buscador diz 2030, quase quatro anos à frente, contra uma recomendação de ficar abaixo de um.

Catorze arquivos dão um Contact que não é um URI. É a armadilha que o formato prepara para quem escreve o que parece óbvio: um endereço solto como psirt@example.com se lê perfeitamente e é inválido, porque o campo está especificado como URI e precisa de mailto: na frente. Uma conhecida empresa de software publica um contato https correto e, na linha seguinte, um endereço solto. Se você precisar montar um, nosso gerador de links mailto escreve o endereço inteiro.

Dezesseis arquivos têm alguma linha que não é um campo, quase sempre um título com espaços, e alguns são prosa pura: um parágrafo explicando como relatar uma falha, publicado no caminho onde se esperava um arquivo legível por máquina. Seis não têm campo Contact nenhum, por terem inventado o próprio nome para ele.

Onde o arquivo fica e o que não é coberto

O padrão é específico quanto ao lugar: o arquivo precisa ficar em /.well-known/security.txt. Uma cópia na raiz do site só é aceita por compatibilidade antiga, e quando as duas existem vale a de well-known. Vinte e seis dos domínios medidos servem nas duas, o que está certo; oito servem só na raiz, de modo que uma ferramenta que siga o padrão pode nunca olhar ali.

O alcance do arquivo é mais estreito do que quase todo mundo supõe. Ele vale só para o domínio ou o IP exatos de onde foi baixado — não para subdomínios e não para o domínio pai. Um arquivo em example.com não diz nada sobre qualquer.example.com, e cada host que precise de um precisa do seu.

Campos desconhecidos não são erros. O padrão manda quem lê ignorar qualquer campo que não reconheça, então o conferidor aponta um nome não registrado como observação, e não como problema. É uma escolha deliberada do padrão, e um validador que marcasse isso como inválido estaria contrariando justamente o documento contra o qual valida.

Dois dos campos que aparecem nesta página não estão em lugar nenhum do RFC 9116. Quem mantém o registro é a IANA, e ele cresceu desde a publicação: CSAF, que aponta para um canal de avisos legível por máquina e é o único campo do formato cujo controle de mudanças não é do IETF, e Bug-Bounty, o único cujo valor não é URI, nem data, nem etiqueta de idioma — é apenas True ou False.

Uma coisa que esta página não faz é verificar assinaturas. Um arquivo pode vir embrulhado numa assinatura OpenPGP, e dezoito dos medidos vêm; os campos de dentro são conferidos normalmente, mas confirmar uma assinatura envolveria lidar com chaves, que é outro trabalho, diferente de ler um formato de texto.

Por que é grátis?

Tudo isso é um formato de texto. Gerar um arquivo é concatenar strings e conferir é um analisador, e as duas coisas rodam no seu navegador, então não há servidor a pagar nem conta a criar.

Nada do que você digita é enviado, guardado ou registrado. Aqui isso pesa mais que na maioria das páginas: um arquivo de contato de segurança é público por natureza, mas o rascunho que você ainda está editando não é, nem o arquivo que você colou para descobrir o que há de errado com ele.