Como funciona esta verificação
O Scanaris pega nos primeiros scripts do teu próprio domínio que a página principal liga, descarrega cada um e procura no fim o comentário //# sourceMappingURL=… que a ferramenta de build deixa. Se existir, resolve esse URL, pede o ficheiro .map e confirma que é mesmo um source map (contém as chaves sources ou mappings). Só então abre o achado, com severidade média. Os source maps embutidos como data: não contam porque não expõem um ficheiro à parte, e um .map que existe mas para o qual nenhum script aponta também não é detetado por esta via.
O que um atacante faz com isto
Com o .map e uma ferramenta gratuita reconstrói o teu código-fonte tal como o escreveste: nomes de variáveis, comentários, estrutura de pastas e, muitas vezes, coisas que julgavas eliminadas. O habitual que aparece: rotas de API internas e de administração, lógica de preços ou de limites que se pode contornar a partir do cliente, comentários do tipo "TODO: tirar esta chave" e funcionalidades desativadas mas não apagadas. Não é uma brecha por si só, mas transforma uma caixa negra numa planta.
Porque são publicados sem querer
Alguns templates ativam os mapas para depurar e ninguém os desativa ao passar a produção. Em Vite, a opção build.sourcemap: true gera-os e acrescenta o comentário; em Next.js, productionBrowserSourceMaps: true; em Nuxt, sourcemap.client: true. Noutros casos gera-os uma integração de monitorização de erros que precisa dos mapas e os deixa na pasta pública em vez de os enviar só para o seu serviço.
Como corrigir
- Vite / Lovable / Bolt: no
vite.config,build.sourcemap: false. Se a tua ferramenta de erros precisa deles, usa o plugin do serviço (Sentry e semelhantes) que os envia no build e os apaga da saída. - Next.js:
productionBrowserSourceMapséfalsepor defeito; confirma que ninguém o mudou nonext.config. - Nuxt:
sourcemap: { client: false }nonuxt.config. - Bloqueá-los no servidor como segunda barreira. Em nginx:
location ~ \.map$ { return 404; }. Na Vercel ou na Netlify basta não os gerar, porque só é servido o que está na pasta de saída.
Se preferires conservá-los para depurar sem os publicar, a opção hidden do Vite gera os ficheiros sem o comentário que os liga; ainda assim, convém não os pôr na pasta pública, porque continuam acessíveis a quem adivinhar o nome.
Confirma que está corrigido
curl -s https://oteudominio.com | grep -oE 'src="[^"]+\.js[^"]*"' | cut -d'"' -f2 | head -3
curl -s https://oteudominio.com/assets/index-XXXX.js | tail -c 200
curl -sI https://oteudominio.com/assets/index-XXXX.js.map | head -1O segundo comando não deve mostrar nenhum sourceMappingURL, e o terceiro deve devolver 404. Se o primeiro comando não listar scripts, a tua página carrega-os por outra via; vê nas ferramentas do navegador, separador Rede.
Perguntas frequentes
Preciso de source maps para perceber os erros de produção?
Sim, mas não têm de ser públicos. Os serviços de monitorização aceitam os mapas no momento do build e associam-nos a essa versão; o navegador nunca os vê.
Os mapas de CSS também são um problema?
Muito menos: expõem as tuas folhas de estilo originais, não lógica. O scanner só revê os de JavaScript.
Porque é severidade média e não alta?
Porque um mapa não dá acesso a nada por si só; facilita encontrar outras falhas. Se além disso o código contém chaves ou rotas de administração sem proteção, esses são os achados graves, e o Scanaris marca-os à parte.