Não Entregue Senhas e Chaves de Pagamento aos Visitantes

Quando alguém abre seu app, o programa usado para acessar sites baixa textos, imagens, botões, cores e instruções necessárias para mostrar a página. Esses arquivos chegam ao aparelho do visitante. A pessoa não precisa enxergar uma senha na tela para encontrá-la; ela pode examinar o que foi baixado. Uma tela de entrada, um botão escondido ou um nome de arquivo difícil de adivinhar não muda isso. Considere público tudo que vai junto com a página, mesmo que sua ferramenta de IA apresente o item como oculto.

A regra simples é que uma senha, chave de pagamento ou código de acesso não pode estar nos arquivos enviados aos visitantes quando permite abrir dados de clientes, alterar cadastros, mandar mensagens como sua empresa ou gastar dinheiro. Os desenvolvedores chamam o conjunto completo de arquivos entregues ao navegador de bundle frontend. Se um código poderoso estiver nesse conjunto, ele poderá ser copiado. Trocar seu nome, dividi-lo em partes ou escondê-lo da página visível não oferece proteção.

Apps precisam de informações comuns para mostrar uma página, como nome, cores, endereço público de atendimento e, às vezes, um identificador que apenas informa qual projeto está usando determinado serviço. O fornecedor pode documentar claramente que esse identificador foi criado para aparecer em público. A presença da palavra chave no nome não decide a questão. O que importa é o que uma pessoa desconhecida conseguiria fazer depois de copiar o item. Consulte a explicação do fornecedor em vez de confiar no rótulo escolhido pela ferramenta.

Faça quatro perguntas sobre cada item configurado: alguém desconhecido conseguiria ler dados de clientes, alterar algo, agir como minha empresa ou gerar uma cobrança? Se alguma resposta for sim, o item precisa ser protegido. O nome técnico de uma senha ou código que concede esse poder é segredo. Ferramentas de IA podem guardar configurações em um campo cujo nome técnico é variável de ambiente. Esse nome explica como uma configuração é fornecida, mas não garante proteção. Se o conteúdo for colocado nos arquivos do visitante, ainda poderá ser copiado.

Em uma tarefa delicada, a tela do visitante deve enviar apenas as informações necessárias, como uma mensagem ou o valor de um pedido. Um computador controlado pelo seu app deve receber a solicitação, conferir a pessoa e a ação pedida, usar a senha ou chave de pagamento protegida e devolver somente o resultado. O nome técnico desse computador protegido é servidor. Os desenvolvedores chamam a parte do app executada nele de backend e chamam o uso exclusivo dos códigos nesse local de tratamento somente no servidor. O código precisa ficar guardado ali e nunca voltar para o visitante.

Levar uma chave de pagamento para um computador protegido é apenas o primeiro passo. Esse computador também deve confirmar quem está pedindo, se a pessoa pode realizar aquela ação e se os dados enviados fazem sentido. Ele deve permitir apenas a menor ação necessária. Por exemplo, um cliente que vai pagar um pedido não deve conseguir escolher o pedido de outra pessoa nem solicitar todos os cadastros. Dê a cada código guardado somente os poderes exigidos pela função e use códigos diferentes para trabalhos sem relação quando o fornecedor oferecer essa opção.

Antes de lançar, abra o endereço publicado em uma janela comum do navegador e teste as funções importantes. Peça à ferramenta para examinar os arquivos criados para os visitantes e procure pelos nomes dos serviços de pagamento, e-mail, armazenamento, mapas e dados de clientes que você conectou. Procure nomes de configurações ligados a senhas, chaves de pagamento e códigos de acesso sem imprimir os valores. Alguns sistemas também criam arquivos auxiliares que facilitam a leitura das instruções geradas. O nome técnico de um desses arquivos é source map, e ele precisa entrar na revisão porque pode revelar cópias legíveis ou nomes importantes.

Faça isso depois da publicação final, pois corrigir o editor nem sempre substitui a versão já disponível aos visitantes. Durante a criação, use contas e códigos de teste quando os fornecedores oferecerem essa opção. Nunca cole uma senha ou chave de pagamento real em uma conversa com IA, pedido de suporte ou lista de tarefas. A VibeCodeWall verifica o app público de fora e acompanha mudanças importantes ao longo do tempo. Ela não precisa ver os arquivos particulares do projeto. Os desenvolvedores chamam as verificações repetidas após mudanças de monitoramento contínuo, que ajuda a encontrar um problema introduzido por uma função nova ou alteração gerada.

Se uma senha, chave de pagamento ou código de acesso chegou a um arquivo público do app, considere que alguém pode ter feito uma cópia. Primeiro, crie um substituto no serviço que forneceu o código. Guarde o novo código somente no computador protegido, atualize o app e confirme que a nova versão pública não o envia aos visitantes. Depois, desative o código antigo na conta do fornecedor. Os fornecedores podem chamar a desativação de revogação. Substituir um código e invalidar o anterior tem o nome técnico de rotação. Não mantenha o código antigo funcionando apenas porque ele sumiu da página mais recente.

Em seguida, abra o histórico de atividades do fornecedor e confira o período em que o código antigo esteve disponível. Procure solicitações desconhecidas, alterações em dados de clientes, mensagens, mudanças na conta ou cobranças relacionadas ao que o código podia fazer. Guarde um registro simples com o serviço afetado, quando o código ficou público, quando foi trocado, quais atividades foram conferidas e quem realizou o trabalho. Continue verificando o app público depois de mudanças importantes. Esse registro evita a restauração acidental do código antigo e oferece informações claras caso você precise falar com o suporte do fornecedor.