Segredos em comentários HTML

Como funciona esta verificação

O Scanaris extrai todos os comentários HTML da tua página principal, ou seja, tudo o que vai entre <!-- e -->, e procura lá dentro seis padrões de segredo. Quatro são formatos de chave reconhecíveis: chaves secretas do Stripe (sk_live_ seguido de 20 ou mais caracteres), chaves de acesso da AWS (AKIA e 16 caracteres), chaves de API da Google (AIza e 35 caracteres) e cabeçalhos de chave privada (-----BEGIN PRIVATE KEY----- e as variantes RSA ou EC). Os outros dois são atribuições explícitas: password, passwd ou pwd seguidos de um valor com pelo menos 6 caracteres, e api_key, secret, token ou bearer seguidos de um valor com pelo menos 16. Se algum coincidir, abre um achado de severidade alta que indica o tipo de segredo encontrado, nunca o valor. Os padrões são estritos de propósito: um comentário que diga "aqui vai o token" sem valor a seguir não é marcado.

Porque importa

Os comentários HTML não se veem na página, mas veem-se no código-fonte, e o código-fonte vê-o qualquer pessoa com Ctrl+U ou com um curl. Não há diferença prática entre pôr uma chave num comentário e publicá-la num fórum. Uma chave secreta do Stripe permite criar cobranças e reembolsos; uma da AWS, usar a tua conta e a tua fatura; uma palavra-passe de base de dados, ler tudo. E os caçadores de segredos automatizados percorrem a web inteira à procura exatamente destes prefixos, por isso o tempo entre publicar a chave e alguém usá-la mede-se em minutos.

Porque acontece

Alguém deixa uma nota para si próprio durante o desenvolvimento ("<!-- utilizador admin / password Temporaria2024 -->"), comenta um bloco de configuração "para testar" em vez de o apagar, ou cola um exemplo de integração com a chave real. Os templates de WordPress e os sites estáticos feitos à mão são os mais propensos, porque os seus comentários chegam ao browser tal e qual. Em frameworks modernas acontece menos, mas acontece: um comentário num .html estático da pasta pública ou num componente que não se compila.

Como corrigir

• Roda a credencial primeiro. Assume que já a leram. Gera uma nova no fornecedor, muda-a no teu servidor e revoga a antiga. Depois apaga o comentário; não ao contrário.
• Procura no projeto antes de fazer deploy, não só na página principal:

grep -rnE "sk_live_|AKIA[0-9A-Z]{16}|AIza[0-9A-Za-z_-]{35}|BEGIN (RSA |EC )?PRIVATE KEY|(password|api_key|secret|token)\s*[:=]" --include=*.html --include=*.vue --include=*.php --include=*.hbs .

• Elimina os comentários em produção. O Vue e o Nuxt tiram-nos ao compilar; no Next.js os comentários JSX nunca chegam ao HTML. Para HTML estático ou WordPress, um minificador (html-minifier-terser com removeComments) ou o plugin de otimização que uses elimina-os. Em PHP, usa comentários de PHP (<?php // ... ?>), que não saem do servidor.
• As credenciais vão em variáveis de ambiente, nunca em ficheiros que se servem. E adiciona um detetor de segredos ao repositório (gitleaks ou a deteção de segredos do GitHub) para que não volte a entrar.

Confirma que está corrigido

curl -s https://teudominio.com | tr -d '\n' | grep -oE '<!--.{0,200}' | grep -iE "sk_live_|AKIA|AIza|PRIVATE KEY|password|api_key|secret|token|bearer"

Não deve sair nada. O ideal é que a primeira parte, sem o último filtro, também não devolva comentários: em produção não fazem falta.

Perguntas frequentes

É uma chave de teste, não de produção.

Os padrões distinguem: sk_test_ do Stripe não é marcado, sk_live_ sim. Se o achado apareceu, é porque o formato coincide com uma chave real ou com uma atribuição explícita de palavra-passe. Se for mesmo um valor fictício, troca-o por algo que não pareça uma credencial, como SUBSTITUIR.

Os comentários do JavaScript também são revistos?

Esta verificação só olha para o HTML. As chaves dentro dos bundles de JavaScript, com ou sem comentário, procura-as segredos em JavaScript, e as referências a hosts internos, referências internas. O que mais foge sem querer está em segredos que a tua app deixa fugir no browser.

Os comentários condicionais do Internet Explorer contam?

São comentários HTML e são analisados da mesma forma, mas não contêm segredos e não são marcados. Ainda assim, em 2026 estão a mais: nenhum browser suportado os interpreta.