Gerador de security.txt

security.txt é uma melhor prática de segurança web formalmente padronizada pela IETF (Internet Engineering Task Force) no RFC 9116, projetada para fornecer aos sites uma maneira unificada e padrão de publicar informações de contato de segurança. Simplificando, é um arquivo de texto colocado em um caminho fixo em um site, dizendo aos pesquisadores de segurança (hackers white hat): "Se você encontrar vulnerabilidades de segurança no meu site, aqui está como nos contatar, aqui está nossa chave pública de criptografia, aqui está nossa política de divulgação e agradecemos seus relatórios."

Antes do padrão security.txt existir, as informações de contato de segurança dos sites eram desorganizadas. Alguns sites não tinham nenhuma informação de contato de segurança, alguns a enterravam em alguma página obscura, alguns só listavam um e-mail info@ não atendido e alguns exigiam busca meticulosa no LinkedIn para encontrar a equipe de segurança. Isso causou um problema sério: quando pesquisadores de segurança de boa-fé descobriam vulnerabilidades, muitas vezes não conseguiam encontrar o canal correto para relatá-las. O resultado foi — muitas vulnerabilidades foram silenciosamente arquivadas, deixadas sem correção, até serem descobertas e exploradas por hackers maliciosos. O security.txt nasceu para resolver esse problema da "última milha".

O conceito de security.txt foi proposto pela primeira vez pelos pesquisadores de segurança EdOverflow e Yakov Shafranovich em 2017 e rapidamente ganhou amplo apoio da indústria. Em abril de 2022, o security.txt foi formalmente aprovado pela IETF como RFC 9116, tornando-se um padrão de segurança web reconhecido internacionalmente. Hoje, grandes empresas de tecnologia como Google, GitHub, Meta (Facebook), LinkedIn e Cloudflare, bem como agências governamentais incluindo o governo do Reino Unido, a CISA dos EUA (Agência de Segurança Cibernética e Infraestrutura), o governo da França, o governo da Itália, o governo da Holanda e o Centro de Segurança Cibernética da Austrália, implantaram o security.txt em seus sites oficiais e recomendam publicamente que outras organizações o adotem.

O design central do arquivo security.txt é muito simples — é um arquivo de texto simples que consiste em linhas no formato "nome-do-campo: valor", semelhante ao formato de cabeçalho HTTP. O padrão define dois campos obrigatórios: Contact (informações de contato de segurança, que podem ser múltiplas) e Expires (tempo de expiração do arquivo); bem como vários campos opcionais: Encryption (URL da chave pública de criptografia PGP), Acknowledgments (URL da página de agradecimentos), Policy (URL da política de divulgação de vulnerabilidades), Hiring (URL de vagas de segurança), Canonical (URL canônica do arquivo), Preferred-Languages (idiomas de relatório suportados) e CSAF (URL de metadados do provedor Common Security Advisory Framework). Este formato simples torna mais fácil para humanos e máquinas analisarem.

Por que implantar o security.txt é tão importante? Primeiro, ele reduz a barreira para o relato de vulnerabilidades. Pesquisadores de segurança não precisam gastar tempo significativo encontrando informações de contato — eles podem encontrar o canal de relatório correto com um clique. Segundo, demonstra a atitude proativa de uma organização em relação à segurança — um site com security.txt está essencialmente dizendo "Levamos a segurança a sério e agradecemos relatórios responsáveis". Terceiro, reduz o risco de vulnerabilidades serem divulgadas publicamente ou exploradas: com um canal formal, os pesquisadores não escolherão divulgar vulnerabilidades publicamente diretamente no Twitter ou GitHub porque não conseguem contatar ninguém. Quarto, em muitos requisitos regulatórios do setor (por exemplo finanças, saúde, governo), estabelecer um canal de divulgação de vulnerabilidades tornou-se um requisito de conformidade.

Existem vários detalhes importantes a serem observados ao implantar o security.txt. Primeiro, o caminho deve estar correto: o caminho padrão é /.well-known/security.txt, e você também pode colocar uma cópia em /security.txt no diretório raiz como fallback. O diretório .well-known aqui é um diretório padrão de "recursos conhecidos" definido pelo RFC 8615, onde outros arquivos padrão como robots.txt também são colocados em locais relacionados. Segundo, deve ser servido por HTTPS — HTTP em texto simples é considerado inseguro. Terceiro, Content-Type deve ser text/plain, não text/html ou outros tipos. Quarto, não faça redirecionamentos entre domínios para security.txt — se https://example.com/.well-known/security.txt redirecionar para https://outro-dominio.com/security.txt, pesquisadores e ferramentas automatizadas considerarão isso suspeito. Quinto, lembre-se de definir o campo Expires e atualizá-lo regularmente; um security.txt expirado será considerado como tendo informações não confiáveis.

O campo Contact é o campo mais importante no security.txt e o único campo verdadeiramente essencial (Expires também é obrigatório, mas é apenas um carimbo de data/hora). Contact suporta três formatos URI: mailto: para endereços de e-mail, https:// para links da web (por exemplo páginas de formulário de relatório de segurança) e tel: para números de telefone. É altamente recomendado fornecer pelo menos um e-mail mailto e um link de formulário https — formulários evitam spam de bots, enquanto e-mail é mais conveniente para pesquisadores enviarem relatórios criptografados diretamente. Vários contatos podem ser listados em várias linhas, por exemplo fornecendo simultaneamente o e-mail da equipe de segurança, o e-mail do líder de segurança e links de plataformas de vulnerabilidades de terceiros.

Embora o campo Encryption seja opcional, é muito importante na prática. Quando pesquisadores de segurança descobrem uma vulnerabilidade crítica (como vazamento de dados de usuário ou execução remota de código), eles absolutamente não querem enviar detalhes de vulnerabilidades em e-mail de texto simples — porque o e-mail passa por vários servidores durante a transmissão, qualquer salto pode ser espionado. A criptografia de chave pública PGP (Pretty Good Privacy) é o padrão da indústria para comunicação segura. Você só precisa gerar um par de chaves PGP, colocar a chave pública em seu site (por exemplo em /.well-known/pgp-key.txt) e inserir essa URL no campo Encryption. Pesquisadores criptografam o conteúdo do relatório com sua chave pública, e apenas aqueles que possuem a chave privada correspondente podem descriptografar e ler.

O campo Policy vincula à sua página de Política de Divulgação de Vulnerabilidades (Vulnerability Disclosure Policy, VDP), que é fundamental para construir a confiança do pesquisador. Uma boa VDP deve declarar claramente: escopo de teste (quais sistemas estão no escopo de teste e quais estão fora do escopo), métodos de teste permitidos (por exemplo teste de SQL injection/XSS permitido, mas DDoS/engenharia social/acesso a dados de usuários reais proibidos), tempos de resposta comprometidos (por exemplo "Confirmaremos o recebimento de relatórios em até 3 dias úteis"), se recompensas são oferecidas e compromissos de porto seguro legal (declarando explicitamente não processar pesquisadores de boa-fé que sigam as regras). Existem muitos modelos VDP disponíveis internacionalmente para referência, e a CISA dos EUA também fornece um modelo VDP de código aberto.

Além do próprio contato de segurança, o security.txt tem vários campos "surpresa". O campo Acknowledgments constrói um Hall da Fama de Segurança — agradecendo publicamente aos pesquisadores que ajudam você a encontrar vulnerabilidades, o que reconhece seu trabalho e também serve como construção de comunidade. O campo Hiring é um design muito inteligente: pessoas que conseguem encontrar vulnerabilidades em seu site são inerentemente excelentes talentos de segurança, e colocar um link de recrutamento no security.txt é o canal mais preciso para recrutar talentos de segurança. Muitas empresas contrataram excelentes engenheiros de segurança através do security.txt. O campo Canonical é uma consideração de segurança — impedindo que atacantes forjem seu security.txt em outros domínios.

Em relação à preocupação comum sobre spam, na prática a maioria das organizações que implantaram o security.txt relata aumentos insignificantes de spam. Isso ocorre porque: primeiro, spammers normalmente não obtêm endereços de e-mail rastreando security.txt; segundo, links de formulário https:// podem ser usados em vez de colocar e-mails mailto diretamente, e adicionar CAPTCHA aos formulários pode bloquear bots completamente; terceiro, e-mails de segurança dedicados (por exemplo security@) geralmente têm filtragem de spam forte configurada. Em contraste, o custo de perder relatórios críticos de vulnerabilidades devido à falta de um canal de contato de segurança supera em muito o aumento potencial de pequenas quantidades de spam.

Este gerador é construído em estrita conformidade com o padrão RFC 9116, e todos os formatos de saída são normalizados: o campo Contact reconhece automaticamente prefixos, o campo Expires usa formato de tempo UTC ISO 8601 padrão e Preferred-Languages é definido automaticamente com base no idioma que você está usando. O conteúdo gerado pode ser copiado e implantado diretamente no caminho /.well-known/security.txt sem quaisquer modificações. Além disso, toda a configuração é feita localmente no seu navegador e nunca é enviada para nenhum servidor — suas informações de contato de segurança sempre permanecem no seu dispositivo. Implantar o security.txt leva apenas 5 minutos, mas o canal de comunicação de segurança que ele estabelece pode ajudá-lo a evitar um incidente de segurança sério no futuro.