Gerador de security.txt — crie e valide um arquivo RFC 9116
Crie um security.txt válido (RFC 9116) com campos de contato, expiração, criptografia e política, verifique um existente e baixe-o para /.well-known/.
Endereços de e-mail, formulários de relato https:// ou números de telefone. E-mails sem prefixo recebem mailto:. Coloque o preferido primeiro.
Data-hora RFC 3339, a menos de um ano. Coloque um lembrete na agenda para renová-lo antes que expire.
URL da sua chave pública PGP (https://, dns: ou openpgp4fpr:), não a chave em si.
Tags de idioma separadas por vírgula, por exemplo en, fr, pt-BR.
A(s) URL(s) https:// onde este arquivo fica. Na prática, obrigatório se você assinar o arquivo.
Sua política de divulgação de vulnerabilidades: escopo, safe harbor, como vocês respondem.
Uma página agradecendo aos pesquisadores que relataram problemas (hall da fama).
Vagas de emprego em segurança.
Para fornecedores que publicam alertas legíveis por máquina: URL do provider-metadata.json.
Válido: todos os campos obrigatórios presentes e todos os valores de acordo com a RFC 9116.
…
- Sirva-o em
https://yourdomain.com/.well-known/security.txtvia HTTPS, comotext/plain; charset=utf-8. Opcionalmente, redirecione/security.txtpara ele. - Next.js, Astro, Vite e a maioria das hospedagens estáticas: salve-o como
public/.well-known/security.txt. WordPress, Apache ou nginx: crie uma pasta.well-knownna raiz do site. - Cada subdomínio que serve seu próprio site deve ter o próprio arquivo (ou indicar o principal num comentário).
- Opcional: assine-o com
gpg --clearsign security.txte publique a saída assinada; inclua Canonical para que a assinatura cubra o local.
Funciona totalmente no seu navegador. Nada do que você digita é enviado para nós nem armazenado. Ver todas as ferramentas grátis.
Encontrou um problema ou algo que poderia ser melhor? Lemos todas as mensagens e corrigimos rápido.
Este gerador de security.txt grátis cria o pequeno arquivo de texto, padronizado como RFC 9116, que diz a pesquisadores de segurança como relatar uma vulnerabilidade no seu site. Preencha um contato, uma data de expiração e, opcionalmente, sua chave de criptografia, política de divulgação, página de agradecimentos, idiomas preferidos e URL canônica; o arquivo é validado conforme a RFC enquanto você digita e é baixado como security.txt, pronto para subir em /.well-known/security.txt.
Sem ele, quem encontra uma falha no seu site precisa adivinhar para onde mandá-la, e os relatos acabam numa caixa de suporte, nas redes sociais ou em lugar nenhum. O arquivo leva cinco minutos e é verificado por muitos scanners de segurança e pesquisadores de bug bounty. A segunda aba valida um arquivo que você já publica. A ferramenta não assina o arquivo (use o gpg para isso) e não busca seu arquivo publicado, porque a página não faz requisições de rede.
Como usar
- Informe pelo menos um Contact: um e-mail de segurança, a URL de um formulário de relato ou um telefone. Coloque o preferido primeiro.
- Defina o Expires com um dos botões (seis meses é um bom padrão) ou digite uma data e hora no formato RFC 3339.
- Adicione os campos opcionais que tiver: a URL da sua chave PGP, sua política de divulgação, uma página de agradecimentos, os idiomas que você lê e a URL canônica do arquivo.
- Corrija o que estiver marcado em vermelho; os itens em âmbar são recomendações.
- Baixe o security.txt e publique-o em https://yourdomain.com/.well-known/security.txt, servido como text/plain. Crie um lembrete para atualizar o Expires.
Perguntas frequentes
O que é o security.txt?
Um arquivo de texto simples em /.well-known/security.txt que informa como relatar vulnerabilidades de segurança num site ou produto. Ele foi publicado como RFC 9116 pela IETF em abril de 2022. Só dois campos são obrigatórios, Contact e Expires; os demais (Encryption, Acknowledgments, Preferred-Languages, Canonical, Policy, Hiring) são opcionais.
Onde coloco o arquivo security.txt?
Em https://yourdomain.com/.well-known/security.txt, servido por HTTPS com o content type text/plain; charset=utf-8. O local antigo /security.txt na raiz ainda é lido por algumas ferramentas; você pode servir uma cópia lá ou redirecioná-lo. No Next.js, Astro, Vite e na maioria das hospedagens estáticas, coloque o arquivo em public/.well-known/. Cada hostname que é um site próprio deve ter seu próprio arquivo.
Por que o campo Expires é obrigatório?
Para que dados de contato desatualizados não sejam considerados confiáveis para sempre. A RFC 9116 torna o Expires obrigatório e recomenda uma data a menos de um ano; quando ela passa, pesquisadores e scanners devem tratar o arquivo como desatualizado. Seis meses com um lembrete na agenda para renovar é um ritmo prático, e o gerador avisa quando a data já passou ou está a mais de um ano.
Devo assinar o security.txt?
Assinar é opcional, mas recomendado. Rode gpg --clearsign security.txt com uma chave cuja parte pública você publica (o campo Encryption pode apontar para ela) e suba a saída assinada no lugar. Se assinar, inclua um campo Canonical, para que uma cópia assinada tirada de uma URL não possa se passar por válida em outra.
Posso usar o link de uma plataforma de bug bounty como contato?
Sim. O Contact aceita qualquer URI https://, então a página de um programa no HackerOne, Bugcrowd, Intigriti ou YesWeHack, ou seu próprio formulário de relato, é válida. Muitas organizações listam tanto um link de plataforma quanto um endereço de e-mail, em ordem de preferência.
Campos da RFC 9116 em resumo
• Contact (obrigatório, pode se repetir): URI mailto:, https: ou tel:. A ordem indica a preferência.
• Expires (obrigatório, exatamente uma vez): data e hora RFC 3339, como 2027-04-30T23:59:59Z; recomenda-se menos de um ano à frente.
• Encryption (pode se repetir): onde obter sua chave pública, como https://, dns: (registro OPENPGPKEY) ou openpgp4fpr: (impressão digital). Nunca cole a chave em si.
• Acknowledgments (pode se repetir): uma página de agradecimento a quem relatou falhas.
• Preferred-Languages (uma vez): tags de idioma separadas por vírgula, ex.: en, fr.
• Canonical (pode se repetir): a(s) URL(s) onde este arquivo deve ficar.
• Policy (pode se repetir): sua política de divulgação de vulnerabilidades.
• Hiring (pode se repetir): vagas na área de segurança.
• CSAF (pode se repetir, registrado pela OASIS): o provider-metadata.json de um feed de avisos CSAF.
URIs web precisam usar https://. Linhas que começam com # são comentários.
O que escrever na sua política de divulgação
O link de Policy é onde os pesquisadores descobrem se é seguro relatar. Informe o escopo (quais domínios e apps), o que está fora do escopo (negação de serviço, engenharia social, saída de scanners automáticos), em quanto tempo você vai confirmar e corrigir os relatos, se oferece recompensas, e uma declaração de safe harbor de que não tomará medidas legais contra pesquisas de boa-fé que sigam a política. Uma página curta e clara rende relatos mais úteis do que uma longa e jurídica.
security.txt e robots.txt
Eles ficam lado a lado, mas fazem coisas diferentes: o robots.txt pede aos crawlers o que não buscar; o security.txt diz às pessoas como chegar ao seu contato de segurança. Não liste o security.txt nem /.well-known/ em Disallow; pesquisadores e scanners precisam lê-lo, e bloqueá-lo no robots.txt não o esconde de qualquer forma.
Ferramentas grátis relacionadas
- Gerador de robots.txt — Monte um robots.txt com predefinições para permitir tudo, homologação e WordPress, uma seção de crawlers de IA (bloquear treinamento, manter a busca com IA) e avisos sobre os erros que tiram sites do índice.
- Gerador de senhas — Gere uma senha aleatória forte, uma frase-senha fácil de lembrar ou um PIN. Funciona inteiramente no seu navegador; nada é enviado nem armazenado.
- Gerador de meta tags — Preencha o título, a descrição e os dados do card social de uma página e receba um bloco <head> completo, com escape correto e contadores de tamanho em tempo real.
- Decodificador JWT — Decodifique o header e o payload de um JWT, leia a expiração em linguagem simples, verifique assinaturas HS, RS, PS e ES ou assine um novo token. Nada sai do seu navegador.