API keys expostas no JavaScript do cliente
Tudo que é enviado ao navegador — scripts inline, JS empacotado, source maps — pode ser lido por qualquer um. Chaves secretas (OpenAI, a secreta do Stripe, AWS, URLs de banco de dados) embutidas no código do frontend estão, na prática, publicadas.
O que é
As ferramentas de build embutem as variáveis de ambiente em tempo de compilação. Se você referenciar um segredo no código do cliente, ele acaba no bundle de JavaScript que todo visitante baixa.
Há uma distinção crucial: chaves publicáveis/anônimas (pk_live do Stripe, a config web do Firebase) são feitas para serem públicas, mas chaves secretas (sk_live, chaves service-role, API keys de provedores) não são e nunca devem chegar ao navegador.
Por que importa
Uma chave de provedor vazada deixa qualquer um acumular consumo na sua conta — contas de LLM, cobranças de SMS, gastos de nuvem — ou acessar os dados que a chave autoriza.
Os atacantes varrem bundles de JavaScript em massa procurando padrões de chaves. Um segredo commitado costuma ser abusado poucos minutos depois de entrar no ar.
Como corrigir
Chame as APIs de terceiros a partir de uma rota de servidor ou backend, nunca do navegador. O navegador conversa com o seu endpoint; o seu endpoint guarda a chave.
// app/api/summarize/route.ts (server-only)
export async function POST(req: Request) {
const { text } = await req.json();
const r = await fetch("https://api.openai.com/v1/responses", {
method: "POST",
headers: { Authorization: `Bearer ${process.env.OPENAI_API_KEY}` },
body: JSON.stringify({ model: "gpt-4o-mini", input: text }),
});
return Response.json(await r.json());
}No Next.js, só as variáveis com o prefixo NEXT_PUBLIC_ são expostas ao navegador. Nunca coloque um segredo atrás desse prefixo — use-o apenas para valores que podem ser públicos sem risco.
Se um segredo foi enviado ao navegador, revogue-o e emita um novo. Removê-lo do próximo build não invalida as cópias que já foram coletadas.
FAQ
Minha chave publicável do Stripe (pk_live) é um problema no frontend?
Não — as chaves publicáveis são feitas para serem públicas. O risco é a chave secreta (sk_live), que precisa ficar no servidor.
Posso simplesmente ofuscar a chave?
Não. A ofuscação é trivialmente reversível. A única correção é manter o segredo totalmente fora do cliente.
Seu app está afetado?
O AppSafe verifica isso e dezenas de outros problemas em um único escaneamento grátis.
Escanear meu app grátisDo blog
Falsos crawlers de IA estão caçando seus arquivos .env. Veja como verificar os seus
Scanners de credenciais usam nomes de crawlers de IA para driblar listas de permissão, e pedem um arquivo em especial: o seu .env. Como verificar se o seu está acessível e como protegê-lo.
O vazamento na Railway: como rotacionar os segredos do seu app sem downtime
A Railway pediu a todos os usuários que rotacionassem suas variáveis de ambiente depois que atacantes foram atrás de API keys de IA e de plataformas. Como verificar sua exposição, rotacionar tudo sem derrubar o app e fazer o próximo vazamento doer menos.
Vai lançar um app criado com IA? Verifique estas 7 coisas antes
As ferramentas de IA otimizam para que "funcione", não para que "seja seguro publicar". Estes são os sete problemas que verificamos primeiro em qualquer app recém-lançado — e a correção de cada um.
Guias relacionados
Arquivos .env expostos: como atacantes acham seus segredos
Um único .env acessível pode entregar toda a sua stack.
Row Level Security (RLS) no Supabase: proteja suas tabelas
Sua anon key é pública. O RLS é a única coisa entre ela e os seus dados.
Firebase Security Rules: pare de deixar seu banco de dados aberto
Sua config do Firebase é pública por design. Suas regras decidem quem vê os dados.
Source maps em produção vazam o seu código-fonte
Arquivos .map publicados entregam o seu código original.