Monte denúncias de abuso para registradores, provedores de hospedagem e CDNs, em e-mail e em JSON.
Gerador de security.txt
A ferramenta em si está em inglês; esta página explica como usá-la no seu idioma.
Use Gerador de security.txt
O que ele faz
Monte um arquivo security.txt para que pesquisadores e pessoas que denunciam phishing que imita a sua marca saibam como falar com você. Salve o resultado como /.well-known/security.txt.
Ele funciona inteiramente no seu navegador: nada do que você digitar é enviado.
Como usar Gerador de security.txt
- Informe um contato. Digite como entrar em contato com sua equipe de segurança na seção “Contato”, um por linha: mailto:security@example.com, um endereço https:// de um formulário de denúncia ou um número de telefone (tel:). Se for apenas um endereço de e-mail, será adicionado “mailto:”.
- Defina a data de expiração. Escolha uma data em Expires. O padrão é daqui a um ano; a RFC 9116 recomenda menos de um ano, então escolha uma data anterior.
- Adicione campos opcionais. Preencha Preferred-Languages (en por padrão), Canonical, Policy, Encryption, Acknowledgments e Hiring, se você os tiver. Campos vazios ficam fora do arquivo.
- Gere e copie. Clique em Generate (gerar) e leia o resultado na caixa de saída. Confira cada endereço mais uma vez, porque a ferramenta os copia como foram digitados, e depois clique em Copy.
- Publique e renove. Salve o texto como /.well-known/security.txt no seu site, via HTTPS, assine-o com gpg --clearsign se quiser e anote uma data para renová-lo antes que expire.
Exemplo
Arquivo mínimo
mailto:security@example.comContact: mailto:security@example.com
Expires: 2027-10-20T23:59:59.000Z
Preferred-Languages: enGera o campo “Contact”: mailto:security@example.com, uma data de validade (Expires) com um ano de antecedência às 23:59:59Z e “Preferred-Languages”: en; os dois campos obrigatórios, além de uma sugestão de idioma, com um lembrete de que a RFC 9116 recomenda que a data de validade (Expires) seja inferior a um ano.
O que ele verifica
| Sinal | O que isso significa |
|---|---|
| Contact: | Uma linha por contato, na ordem em que você os digitou. Cada um deve ser um URI do tipo mailto:, https:// ou tel:, conforme especificado pela RFC 9116; http:// e valores inválidos geram um erro em vez de um arquivo. |
| Expires: | A data escolhida às 23:59:59 UTC, escrita com milissegundos, por exemplo 2027-03-31T23:59:59.000Z. Se você limpar o campo de data, Generate deixa de produzir um novo arquivo. |
| Preferred-Languages: | en por padrão. Use códigos de idioma separados por vírgula, como en, de, ou limpe o campo para deixar a linha de fora. |
| Canonical: | O endereço https:// completo onde este arquivo fica, para que uma cópia servida de outro lugar possa ser reconhecida. |
| Encryption: | Um link para a sua chave pública OpenPGP, para que quem denuncia possa criptografar detalhes sensíveis. |
| Policy, Acknowledgments, Hiring | Links para a sua política de divulgação, para uma página de agradecimento a quem denuncia e para vagas de segurança. Todos opcionais, e a ferramenta não verifica se os links funcionam. |
| Um endereço de função em Contact | Use um endereço ou um formulário acompanhado por uma equipe, como security@ do seu domínio, e não a caixa de e-mail de uma pessoa, para que as denúncias continuem chegando quando as pessoas mudarem de emprego. |
| Error: Contact is required | Exibido quando o campo “Contato” estiver vazio. Qualquer erro substitui a saída por uma nota informando que nada foi gerado até que os campos sejam corrigidos. |
Mais exemplos
Formulário web com idiomas e política
Contact https://example.org/report-security, Expires 2027-03-31, Preferred-Languages en, de, Canonical https://example.org/.well-known/security.txt, Policy https://example.org/security-policyCinco linhas, nesta ordem: Contact: https://example.org/report-security, Expires: 2027-03-31T23:59:59.000Z, Preferred-Languages: en, de, Canonical: https://example.org/.well-known/security.txt, Policy: https://example.org/security-policy.
Contato por e-mail com chave, sem idioma
Contact mailto:abuse@example.net, Expires 2027-06-30, Preferred-Languages cleared, Encryption https://example.net/pgp-key.txtTrês linhas: Contact: mailto:abuse@example.net, Expires: 2027-06-30T23:59:59.000Z e Encryption: https://example.net/pgp-key.txt.
Contact deixado vazio
All fields filled except ContactErro: É necessário preencher o campo “Contato”, e há uma nota informando que nada foi gerado. Os demais campos mantêm seus valores; portanto, preencha o campo “Contato” e clique em “Gerar” novamente.
Perguntas frequentes
Quais campos são obrigatórios?
A RFC 9116 exige pelo menos um campo “Contact” e exatamente um campo “Expires”; os demais são opcionais. Cada linha “Contato” deve ser um URI do tipo “mailto:”, “https://” ou “tel:” (um endereço de e-mail simples tem “mailto:” acrescentado); o campo “Expires” deve conter uma data futura; e o campo “Generate” exibe um erro em vez de um arquivo quando um desses campos estiver ausente ou inválido.
Que data devo colocar em Expires?
A data padrão é definida como um ano a partir de hoje, embora a RFC 9116 recomende um prazo inferior a um ano; portanto, escolha uma data anterior para seguir essa recomendação; a página avisa quando a data estiver a mais de um ano à frente. Renove o arquivo antes dessa data, pois a RFC estabelece que um arquivo security.txt vencido deve ser tratado como desatualizado.
Ele envia ou assina alguma coisa?
Não. O arquivo é montado no seu navegador e nada é enviado a lugar nenhum. Ele não é assinado; a RFC 9116 recomenda uma assinatura OpenPGP em texto claro, que você pode adicionar com gpg --clearsign antes de publicar.
Posso listar mais de um contato?
Sim. A RFC 9116 permite várias linhas de contato, que são lidas por ordem de preferência. Digite um contato por linha no campo “Contato”; os contatos duplicados são gravados apenas uma vez.
Onde exatamente o arquivo deve ficar?
Em https://seu-domínio/.well-known/security.txt, servido via HTTPS como texto simples. Uma cópia ou um redirecionamento em /security.txt é opcional.
Um arquivo cobre os meus subdomínios?
Não. A RFC 9116 diz que um security.txt vale só para o host de onde foi obtido, não para os subdomínios nem para o domínio pai. Publique uma cópia em cada host onde as pessoas possam procurar, como www e shop.
Como o security.txt ajuda contra phishing que copia a minha marca?
Quem encontra um site parecido ou um e-mail falso em seu nome muitas vezes quer avisar você. Uma linha Contact que funciona leva essa denúncia à sua equipe de segurança em vez de a uma fila de suporte geral, para que você possa agir mais cedo contra o domínio parecido.