Source maps expostos: seu app está publicando o código original

Você escaneou seu app, e uma linha do relatório diz que seu código-fonte original está publicado. Ou alguém técnico apertou F12 no seu site e disse que seus source maps estão expostos. De um jeito ou de outro, soa mal de uma forma específica e pessoal: a coisa que você passou meses construindo está, pelo visto, largada à vista de todos, comentários incluídos.

A leitura alarmada e o dar de ombros erram as duas. Um source map não é um segredo. É um mapa (o nome é literal) para onde os seus segredos estariam, se algum dia algum acabou escrito no seu código. Se o seu importa depende do que há lá dentro, e conferir leva uns 30 segundos.

É ruim que seus source maps estejam expostos?

É algo para consertar nesta semana. Raramente é motivo de pânico hoje à noite.

O que um source map exposto revela é código, e seu app já entrega o próprio código a cada visitante, comprimido num bloco ilegível, mas presente, porque a web funciona assim. Um estranho paciente, com as ferramentas certas, conseguiria reconstruir uma versão aproximada só a partir do arquivo comprimido. O mapa elimina a exigência de paciência: com ele, qualquer pessoa que aperte F12 lê o seu projeto arrumado do jeito que aparece no seu editor.

Nosso scanner classifica um source map publicado como médio, o meio da escala de severidade, e essa posição é proposital. Sozinho, código legível é uma perda de privacidade: alguém pode estudar como seu app funciona, ler suas funções pela metade, pegar emprestadas as suas ideias. Desagradável, e para um app cujo valor é um prompt engenhoso ou um fluxo incomum, um problema de negócio real. Não um caixa aberto.

O peso muda no dia em que seu código contém algo que nunca deveria ter sido código. Uma chave que roda como parte do seu app acaba também no arquivo comprimido. O mapa a torna mais fácil de achar, mas ela já estava publicada, e isso é um achado próprio, maior. Comentários são diferentes. A compressão os apaga do que é entregue, então o mapa é o único lugar público onde um comentário existe. Uma senha numa linha comentada, uma nota remove before launch em cima da coisa que nunca foi removida, um endereço interno anotado ao lado da função que o chama: nada disso está ao alcance de um estranho a não ser no mapa.

O que é um source map, afinal

É a tradução entre o código que seu site entrega e o código que você escreveu.

Quando seu app é publicado, a etapa de build comprime o código: todos os arquivos espremidos juntos, cada nome encurtado para uma ou duas letras, cada comentário removido, tudo numa única linha enorme. Navegadores executam isso sem reclamar. Ninguém consegue ler, nem as ferramentas que o construíram, e isso vira problema no momento em que algo quebra e o erro aponta para a linha 1, caractere 48.120, de um arquivo que nenhum humano jamais viu.

Então as ferramentas de build escrevem um segundo arquivo, o source map. Ele fica ao lado do comprimido (app.js ganha app.js.map) e guarda tudo que a compressão jogou fora: seus arquivos originais, seus nomes, a estrutura de pastas e cada comentário. A última linha do arquivo comprimido carrega o endereço do mapa, e um navegador o baixa quando as ferramentas de desenvolvedor abrem. Esse é todo o desenho. Ele existe para que um erro possa apontar para o código que você escreveu de verdade.

Duas coisas seguem desse desenho. Seus visitantes nunca baixam o mapa (um navegador só o pede quando as ferramentas de desenvolvedor abrem), então um mapa publicado não custa nada, não muda nada na tela e nunca se anuncia. E qualquer coisa que consiga abrir seu site consegue baixar o mapa, porque o endereço está escrito na página e não há login na frente. Se o arquivo está lá é um ajuste de build, e de fora, ligado parece exatamente igual a desligado até alguém ir olhar.

Como verificar seu app em 30 segundos

No seu app no ar, o endereço publicado que seus usuários visitam, não a prévia dentro do builder:

1. Abra o app no Chrome, Edge ou Firefox e aperte F12. Isso abre as ferramentas de desenvolvedor do navegador, o mesmo painel que um estranho usaria.
2. Clique na aba Sources, no topo do painel.
3. Leia a árvore de arquivos à esquerda. Código comprimido aparece como um ou dois arquivos com nomes tipo index-4f81ab2c.js. Source maps aparecem como o seu projeto: uma pasta chamada src, arquivos com os nomes das suas páginas e componentes, e dentro deles código que dá para ler de verdade.

Se você consegue abrir um arquivo ali e ver seus próprios comentários, seus source maps estão publicados. O navegador só desenha aquela árvore porque baixou o mapa do seu site no ar, exatamente como faria o navegador de qualquer outra pessoa.

Se preferir não fuçar em painéis, nosso scan gratuito lê seu site no ar de fora e relata esta verificação junto com outras oito: escanear seu app. Leva uns 20 segundos e não pede conta.

O que um estranho consegue ver, e o que não

Tudo que você escreveu dentro do próprio app, e nada além dele.

Source maps publicados revelam o seu frontend: suas páginas, seus componentes, a lógica que roda no navegador, os nomes das rotas que seu app chama, qualquer prompt que você tenha escrito dentro do app e cada comentário.

Eles não alcançam seu servidor. Código rodando numa edge function ou num backend fica onde está. Também não abrem seu banco de dados. Se um estranho pode ler suas tabelas é decidido pelas regras de cada tabela, não pela visibilidade do seu código, e essa pergunta nós medimos em separado nos mesmos apps.

Na prática, o dano de um mapa publicado chega como leitura silenciosa, não como uma invasão dramática: alguém estuda sua lógica de checkout procurando um jeito de contorná-la, ou encontra uma rota de administração que ninguém nunca linkou e a testa. Cada uma dessas coisas só vira problema se o que foi encontrado estava desprotegido. O mapa é um guia para o estranho; ele não é, em si, a porta aberta.

Com que frequência source maps publicados aparecem

Em agosto de 2026 escaneamos 30.998 apps no ar publicados a partir de Lovable, Base44, Replit, v0 e Bolt. Um em cada oito (13%) servia pelo menos um source map em funcionamento.

Só contamos um mapa quando ele responde de verdade. O endereço no fim de um arquivo comprimido não prova nada sozinho, porque muitos builds escrevem o endereço e nunca sobem o arquivo; nosso scanner o segue e confere que um mapa real volta. E onde a verificação não pôde ser concluída, registramos que não pôde ser concluída. Um app que não conseguimos verificar é desconhecido, não limpo.

Dois outros números da mesma varredura colocam este no seu lugar. O vazamento sobre o qual donos de app mais recebem aviso (uma chave secreta na página, do tipo que ignora toda regra do banco de dados) apareceu 3 vezes nesses 30.998 apps. E uma tabela de banco de dados legível por qualquer estranho apareceu em mais da metade dos apps em que conseguimos concluir essa verificação. Source maps expostos ficam entre os dois: bem mais comuns que o vazamento famoso, bem menos diretamente danosos que a tabela aberta. Que é exatamente o que uma severidade média está tentando dizer.

Como desligar os source maps em produção

Um ajuste de build, e depois um novo deploy.

Se um builder fez seu app, diga a ele em palavras simples, em inglês, onde os builders são mais confiáveis:

Disable source map generation for production builds and redeploy.

Se você mesmo gerencia o código, o ajuste mora na configuração de build. Num projeto Vite (que é o que existe por baixo da maioria dos apps de Lovable e Bolt) é build.sourcemap: false no vite.config; um app Nuxt tem sua própria opção sourcemap. Faça o deploy de novo e repita a verificação de 30 segundos: a árvore de arquivos legível em Sources deve ter sumido, e só os nomes comprimidos devem restar.

Dois arremates antes de dar isso por encerrado. Desligar os mapas não recolhe as cópias. Quem baixou seu mapa enquanto ele esteve no ar continua com seu código do jeito que ele era naquele dia. Então leia seu próprio código antes de relaxar: se em algum lugar há uma chave, uma senha ou qualquer outra coisa que não deveria ser pública, rotacione agora; remover o mapa fecha a porta para leitores novos, não para o que já foi copiado. E o ajuste pode voltar: uma atualização de template, uma configuração regenerada ou um novo destino de deploy pode religar os mapas sem você encostar em nada.

O que fazer agora

Esse último hábito é o que escorrega, porque nada parece diferente quando a resposta muda. O Reeve Care roda este mesmo scan contra o seu app no ar num calendário, esta verificação incluída, e escreve para você quando um resultado piora: o que ele vigia e quanto custa.

Se preferir fechar tudo de uma vez, o checklist de segurança de 10 minutos cobre isto junto com as outras portas que valem uma olhada num app recém-lançado.