Como funciona esta verificação
O Scanaris pede /.well-known/security.txt, que é o caminho padrão da RFC 9116, e se não o encontrar tenta /security.txt na raiz, a localização antiga. Dá o ficheiro por presente apenas se responder 200 e contiver uma linha que comece por Contact:, o único campo obrigatório juntamente com Expires. Assim exclui as aplicações de página única que devolvem o seu HTML para qualquer caminho. Se não o encontrar, abre um achado de severidade informativa: não tira pontos à tua nota, porque não o ter não é uma falha de segurança; é uma boa prática que te falta.
Para que serve
Quando alguém encontra uma falha no teu site (um investigador, um utilizador curioso, outra empresa), precisa de saber a quem avisar. Sem um canal claro, o normal é não avisar, publicar, ou escrever para o formulário de contacto genérico que ninguém lê. O security.txt é um ficheiro de texto num caminho conhecido onde dizes "escreve-me aqui, nesta língua, e esta é a minha política". É lido por pessoas e por ferramentas, e cada vez mais programas de recompensas e seguradoras o dão por adquirido. Também te protege a ti: deixa claro que aceitas reportes responsáveis e em que condições.
Como criá-lo
Um ficheiro mínimo válido:
Contact: mailto:security@teudominio.com
Expires: 2027-10-01T00:00:00.000Z
Preferred-Languages: pt, en
Canonical: https://teudominio.com/.well-known/security.txt- Contact (obrigatório): um
mailto:, um URL de formulário ou umtel:. Podes pôr vários, por ordem de preferência. A caixa de correio tem de existir e ser lida. - Expires (obrigatório): data em formato ISO 8601 a partir da qual o ficheiro deixa de ser válido. A RFC recomenda menos de um ano: põe um lembrete para o renovar.
- Preferred-Languages, Policy (URL da tua política de divulgação), Encryption (a tua chave PGP) e Acknowledgments (página de agradecimentos) são opcionais.
- Canonical indica o URL oficial do ficheiro; útil se assinares o ficheiro com PGP para que ninguém possa publicar um falso.
Onde o colocar
- Nuxt, Next.js, Vite, Astro: cria
public/.well-known/security.txt; é servido tal e qual. Confirma que o.gitignorenão ignora pastas que começam por ponto. - Vercel e Netlify: o mesmo, dentro da pasta pública do projeto.
- nginx ou Apache: um ficheiro em
/.well-known/security.txtdo diretório servido; se a tua aplicação captura todas as rotas, adiciona uma exceção para/.well-known/. - WordPress: envia o ficheiro por FTP para
.well-known/na raiz, ou usa um plugin que o gere.
Serve-o como text/plain e em HTTPS. Se tens muitos domínios, cada um deve ter o seu ou redirecionar para o canónico.
Confirma que está corrigido
curl -si https://teudominio.com/.well-known/security.txt | grep -iE "^(HTTP|content-type|contact|expires)"Esperado: 200, tipo text/plain, uma linha Contact: e uma Expires: com data futura.
Perguntas frequentes
Vou receber mais spam ou e-mails de "caçadores de recompensas"?
Algum correio de baixa qualidade vai chegar; é o preço de seres localizável. Um filtro simples e uma política clara (o que conta como reporte válido, se pagas ou não) reduzem o ruído. O que te poupa é a alternativa: saberes pelo Twitter.
Posso pôr só o formulário de contacto geral?
Podes, mas é melhor uma caixa dedicada que alguém reveja. Se o formulário geral é lido pelo marketing, um aviso de vulnerabilidade pode levar semanas a chegar a quem deve.
Porque não penaliza a nota?
Porque mede preparação, não exposição. As restantes verificações de segurança, as que pesam mesmo, estão na checklist de segurança antes de lançar.