Chaves de API e variáveis de ambiente em um IDE de navegador

A primeira regra é desconfortável, mas simples: um aplicativo web estático não consegue guardar um segredo. O navegador baixa HTML, CSS e JavaScript e os executa na máquina do usuário. Qualquer pessoa pode abrir o DevTools, ler o painel de rede, pesquisar o bundle ou definir um breakpoint e inspecionar uma variável. Minificar o código, dividi-lo em chunks ou esconder um valor em um arquivo de configuração muda o esforço, não o resultado. Um IDE de navegador adiciona um sandbox para executar o código do projeto, mas a interface do próprio IDE continua rodando na mesma origem e precisa ler o que for necessário para funcionar. O sandbox não é um cofre para valores que a própria interface precisa usar. O teste útil é direto: se um valor precisa estar disponível para o código que roda na aba, presuma que a pessoa que usa a aba pode lê-lo, e que qualquer script na mesma origem também pode. Isso não torna o desenvolvimento no navegador inseguro. Define a fronteira. Identificadores públicos podem ficar ali; credenciais de servidor não.

Em um servidor Node.js, uma variável de ambiente é lida em tempo de execução a partir do processo. Em um build de Vite, Create React App, Next.js ou Astro, as variáveis de ambiente públicas funcionam de outra forma: o bundler substitui as referências por strings literais durante o build. O Vite expõe variáveis com o prefixo VITE_ por meio de import.meta.env; o Create React App usa REACT_APP_; o Next.js usa NEXT_PUBLIC_; o Astro usa PUBLIC_. O prefixo é uma convenção de nomes, não um controle de segurança. Depois que um valor é embutido, ele faz parte do JavaScript que cada visitante baixa. Uma variável sem prefixo público normalmente não fica disponível para o código do cliente, e é por isso que valores exclusivos do servidor precisam ser lidos por um servidor ou uma função serverless, não por uma página estática. Um arquivo .env é uma entrada de desenvolvimento e build, não um cofre de segredos em tempo de execução. Ele é útil para configuração local e para manter valores fora do controle de versão, mas não torna um valor privado depois do build.

# Safe to expose: a public endpoint
VITE_API_URL=https://api.example.com

# Never expose: keep this on a server
STRIPE_SECRET_KEY=REPLACE_WITH_SERVER_SECRET

Algumas chaves são feitas para serem públicas. Uma chave publicável do Stripe identifica uma conta e cria tokens de pagamento; a chave secreta realmente movimenta dinheiro e precisa ficar em um servidor. Uma chave anon do Supabase só é segura quando as políticas de row-level security estão corretas. Uma configuração web do Firebase identifica um projeto, mas não concede acesso administrativo. Chaves de mapas e de medição de uso costumam ser restritas por domínio ou API. Esses valores podem ir para o navegador, mas ainda merecem limites: origens permitidas, restrições de API, papéis com privilégios mínimos, cotas e alertas. A categoria oposta é mais fácil de enumerar. Chaves de service role, senhas de banco de dados, credenciais SMTP, segredos de assinatura e chaves privadas de provedores de IA nunca devem estar em um bundle estático. Uma chave de provedor que pertence à aplicação é especialmente perigosa: quem a encontrar pode gastar o dinheiro da aplicação. Uma chave que pertence ao usuário é outro caso. Continua sendo uma credencial bearer, mas é dele, e o objetivo é mantê-la no navegador do usuário, não no projeto ou no repositório.

O painel de IA do GB Coder funciona no modelo bring-your-own-key. O gerenciador de chaves mantém as chaves de provedor na memória por padrão. Ele não as grava no localStorage. O usuário pode optar explicitamente por persistir no sessionStorage, o que limita o valor à aba atual e normalmente o apaga quando a aba fecha. A chave é removida da memória e do armazenamento de sessão quando o usuário a apaga. O gerenciador também vincula cada chave a uma origem de endpoint autorizada, e um gateway de saída verifica se a credencial não está sendo enviada a um destino não aprovado. Erros de provedores passam por uma camada de redação que remove padrões de chave e chaves ativas antes que a mensagem chegue à interface ou a um log. Metadados de provedores personalizados são armazenados no localStorage, mas cabeçalhos marcados como secretos são apagados antes da persistência e precisam ser digitados novamente. As requisições vão diretamente do navegador para o endpoint do provedor; o GB Coder não faz proxy da chave por um servidor da LadeStack. Essas medidas reduzem a persistência acidental e vazamentos entre origens. Não mudam a regra básica: qualquer script que consiga rodar na mesma origem pode ler o que a página lê. Use um perfil limpo para trabalho sensível e não instale extensões não confiáveis.

Mantenha segredos fora da árvore do projeto. Adicione .env e suas variantes locais ao .gitignore e faça commit de um .env.example com nomes de espaço reservado. Se o projeto usa Vite, lembre-se de que toda variável VITE_ é embutida no bundle de produção. Um valor conveniente durante o desenvolvimento local se torna público no momento em que é usado em um build de produção. Antes do deploy, inspecione os assets gerados em busca de padrões de chave e trate qualquer ocorrência como incidente, não como aviso. A verificação de segredos e a proteção de push do GitHub podem detectar alguns formatos de token conhecidos, mas são uma rede de segurança, não um substituto para manter os valores fora do repositório. A exportação ZIP de um IDE de navegador inclui os arquivos do projeto. Se houver um arquivo .env dentro do projeto, ele viaja com o backup. Um backup não é um cofre criptografado. Guarde as exportações em um local privado e exclua cópias antigas quando não forem mais necessárias. O mesmo vale para capturas de tela, relatos de problemas e mensagens de chat: uma chave colada em qualquer um deles já saiu do navegador.

# .gitignore
.env
.env.local
.env.*.local

Tokens de acesso pessoal do GitHub e tokens de deploy são mais poderosos do que parecem. Um token clássico com escopos repository e workflow pode ler código privado, alterar arquivos e disparar releases. Prefira tokens fine-grained com um único repositório, uma lista explícita de permissões e uma data de expiração. Dê ao token apenas as permissões de que a tarefa precisa: leitura e escrita de contents para uma sincronização, sem administration ou billing. Crie tokens separados para dispositivos ou finalidades diferentes e revogue-os quando o trabalho terminar. Tokens de deploy da Vercel ou da Netlify podem publicar, substituir ou excluir projetos. Se o provedor oferece escopo por projeto ou equipe, use; se oferece expiração, defina uma. Cole o token no painel de deploy apenas quando necessário e não o salve em um arquivo do projeto. Em CI, use segredos do repositório ou da organização em vez de um .env commitado, e lembre-se de que pull requests de forks normalmente não recebem segredos. Um token que foi capturado em screenshot, compartilhado em um chat ou commitado em um repositório público deve ser tratado como comprometido, mesmo que tenha sido excluído um segundo depois.

Uma chave de provedor de IA é uma credencial bearer com uma fatura anexada. Quem a tiver pode enviar requisições, consumir cota e gerar cobranças. Use uma chave limitada a um projeto, defina um limite de gastos quando o provedor oferecer e use uma chave separada para experimentos em vez da chave mestra da organização. Verifique o uso regularmente, especialmente depois de compartilhar um dispositivo ou instalar uma nova extensão. Provedores locais como Ollama, LM Studio e vLLM não precisam de chave na nuvem, mas seus endpoints continuam sendo serviços na máquina. Não exponha um endpoint local à internet pública só para fazer uma demonstração funcionar. Se um provedor personalizado aponta para um proxy, o proxy pode ver a chave; use apenas um proxy que você controla e entende. Prompt injection é um risco relacionado: um arquivo, uma página web ou uma mensagem de erro colada pode conter instruções voltadas ao assistente. Mantenha segredos fora dos prompts e dos arquivos que o assistente tem permissão para ler. Se uma chave aparecer em uma conversa, rotacione-a.

Um computador compartilhado ou de laboratório exige uma rotina diferente. Use um perfil de navegador privado, não opte pela persistência de sessão e feche a aba ao terminar. Se o navegador oferecer para salvar a chave, recuse. Limpe o armazenamento do site se suspeitar que ele foi mantido. Extensões de navegador também fazem parte da fronteira: uma extensão com permissões amplas de host muitas vezes pode ler o conteúdo ou o armazenamento da página, e uma atualização maliciosa pode chegar depois da instalação. Use um perfil mínimo para trabalhos que envolvem credenciais. Cross-site scripting é o risco web clássico nesse contexto. Se um atacante conseguir executar um script na origem do IDE, esse script pode ler localStorage e sessionStorage e fazer requisições enquanto a página estiver aberta. Mantenha as dependências atualizadas, evite scripts de terceiros não confiáveis e considere uma content security policy no site implantado. Gerenciadores de área de transferência e ferramentas de compartilhamento de tela também veem o que você copia e exibe. Limpe a área de transferência depois de mover uma chave e pause o compartilhamento antes de abrir um painel de configurações do provedor.

Rotação é a única resposta confiável para uma chave vazada. Revogar primeiro é importante: se a chave antiga continuar válida enquanto a substituição é preparada, a exposição continua. Crie a nova chave com o escopo mais estreito que funcione, atualize a aplicação ou as configurações do navegador, refaça o deploy se o valor fazia parte de um build e verifique se a chave antiga é rejeitada. Depois, confira o uso e os logs de auditoria do provedor em busca de atividade inesperada. Se a chave foi commitada no Git, apagar o arquivo não basta; o valor permanece no histórico. Rotacione primeiro, depois reescreva o histórico com uma ferramenta como git filter-repo ou BFG, faça force-push com o acordo da equipe e peça aos colaboradores que clonem novamente. Plataformas de hospedagem podem armazenar builds antigos em cache, então garanta que o valor antigo não possa ser servido a partir de um bundle desatualizado. Se a chave foi colada em um chat de IA, um ticket de suporte ou uma captura de tela, presuma que foi retida e rotacione. Por fim, registre o que aconteceu, adicione uma verificação que teria detectado o problema e encurte a vida útil da próxima chave.

Use esta sequência antes que um projeto saia do navegador. Primeiro, classifique cada valor: identificador público, credencial de usuário ou segredo de servidor. Segundo, mantenha segredos de servidor fora do bundle estático e coloque-os atrás de uma função serverless ou API. Terceiro, exponha apenas valores que precisam do prefixo público e inspecione os assets compilados antes do deploy. Quarto, mantenha arquivos .env fora do Git, faça commit de um .env.example e ative a verificação de segredos. Quinto, crie tokens com escopo e expiração para GitHub e hospedagem, um por finalidade. Sexto, no GB Coder, deixe as chaves na memória a menos que esteja em um dispositivo confiável, e opte pela persistência de sessão apenas quando entender o trade-off. Sétimo, nunca cole uma chave em um prompt, uma issue, uma captura de tela ou um arquivo do projeto. Oitavo, rotacione em qualquer dúvida e revogue antes de substituir. Nono, use um perfil de navegador limpo em máquinas compartilhadas. Décimo, escreva o plano para um vazamento antes de precisar dele. Um IDE de navegador pode lidar com credenciais de forma responsável quando trata o navegador como um cliente público, não como um cofre privado.