Site bonito, segurança de papel: o risco do vibe coding sem critério

Imagine a cena. Alguém abre o notebook para mostrar o sistema que acabou de construir. A interface é bonita, os gráficos deslizam, o botão tem uma animação caprichada. Já existe até uma página de planos. Você pergunta:

— Site bonito! Qual tecnologia você usou?

— Claude Code.

A resposta vem com aquele entusiasmo de quem acabou de descobrir o fogo. E eu entendo. Transformar uma ideia em algo que funciona dá uma satisfação enorme. Ver isso acontecer com a ajuda de IA pode dar a sensação de que uma porta, antes trancada, finalmente se abriu.

Mas a conversa continua. Onde os dados ficam? Quem pode acessá-los? Como uma senha é armazenada? O que impede um cliente de consultar as informações de outro?

Silêncio.

É desse intervalo entre “consegui fazer” e “estou preparado para entregar” que quero falar. Em 2026, essa situação tem aparecido nas conversas e nos projetos aos quais dou suporte. É uma percepção da minha experiência, não uma estatística sobre todo mundo que usa IA.

“Claude Code” ainda deixa muita coisa sem resposta

A documentação da Anthropic apresenta o Claude Code como uma ferramenta de programação com IA capaz de ler projetos, editar arquivos e executar comandos. Portanto, dizer que você o utilizou informa uma parte do processo de construção. Ainda falta explicar o sistema produzido. Fonte: Anthropic.

É mais ou menos como perguntar de que material uma casa foi construída e ouvir: “Usei uma parafusadeira excelente”. Ótimo equipamento. Agora vamos conversar sobre a estrutura.

Você pode ter criado uma aplicação em PHP com Laravel, uma interface em React, um serviço em Python ou uma página estática. Pode usar banco próprio, serviço gerenciado ou nem precisar armazenar dados. Cada escolha traz responsabilidades diferentes.

Ninguém precisa decorar uma sopa de siglas para merecer entrar na área. Mas, ao oferecer um produto a clientes, precisa conseguir explicar o que ele faz, onde estão as informações e quem responde por sua manutenção. Se ainda não consegue, esse é um assunto para aprender e revisar antes da entrega.

O rótulo vibe coder cabe em experiências muito diferentes. Aqui, minha crítica é pontual: entregar um sistema que lida com dados reais sem compreender nem verificar os controles que deveriam protegê-los.

Quando admin123 vira crachá de administrador

Nos últimos tempos, dando suporte a empresas, departamentos e instituições, encontrei uma situação cuja lógica pode ser resumida assim:

se senha == "admin123":
    usuário é administrador

Esse trecho é uma representação simplificada do problema que relatei, não a reprodução de um sistema identificável. O ponto era justamente aquele: a comparação com uma senha fixa funcionava como a única validação para definir quem era administrador.

Dá para imaginar a apresentação. A pessoa digita a senha, o painel abre, os botões aparecem. Tudo parece funcionar. Só que o teste demonstrou que a porta abre com aquela combinação. Ainda falta demonstrar quem recebeu a chave e quais portas essa pessoa deveria conseguir abrir.

Credenciais embutidas no código têm uma classificação conhecida: CWE-798, no catálogo da MITRE. Se uma senha secreta estiver no código enviado ao navegador, pode ser recuperada por quem recebe esse código. Se estiver apenas no servidor, continua sendo uma credencial fixa que precisa de tratamento adequado. Fonte: MITRE.

Trocar admin123 por uma frase enorme, cheia de símbolos, pode continuar deixando intacta a lógica errada. A revisão precisa alcançar a identidade do usuário, a atribuição de privilégios e as operações protegidas. Colocar uma senha mais comprida na mesma gambiarra não transforma a gambiarra em arquitetura.

Senha guardada exige mais do que um cadeadinho na tela

Quando alguém fala que “as senhas precisam de criptografia”, vale ajustar o termo. Para senhas de login, a orientação habitual é usar hash específico para senhas, como Argon2id, com configuração apropriada. O objetivo é conferir a senha sem guardar seu texto original para recuperá-lo depois. Fonte: OWASP.

As diretrizes do NIST acrescentam salt e fator de custo a esse processo: elementos que dificultam as tentativas de adivinhação quando alguém obtém os hashes. Isso não torna uma senha fraca invencível. HTTPS protege a comunicação; armazenar a senha adequadamente é outra responsabilidade. Fonte: NIST.

Para quem está começando, minha sugestão é recorrer aos mecanismos de autenticação de frameworks e serviços consolidados, entendendo sua configuração. Inventar uma proteção porque “a IA disse que está seguro” cria uma dívida que talvez você só descubra quando alguém apresentar a cobrança.

E não vale mandar um “adicione segurança” ao agente, receber uma resposta tranquilizadora e encerrar a revisão. O resultado precisa ser conferido por alguém capaz de explicar o que mudou e verificar se aquilo realmente protege a operação.

O navegador não pode distribuir os crachás

Autenticação verifica a identidade. Autorização decide o que aquela identidade pode fazer. A OWASP recomenda verificar permissões em cada requisição, numa camada confiável, como servidor, gateway ou função serverless. A decisão não deve depender apenas de verificações no navegador. Fonte: OWASP.

Esconder o botão “Excluir cliente” ajuda a organizar a interface. A operação de exclusão também precisa recusar quem não tem permissão. Da mesma forma, entrar na própria conta não deveria liberar os registros de todos os demais clientes.

Pense num clube: a pessoa apresentar uma carteirinha na recepção não dá a ela autorização automática para abrir o caixa, entrar no arquivo e levar a televisão. Cada acesso tem uma regra.

Na apresentação comercial, todos costumam seguir o caminho esperado: entrar, cadastrar, salvar. Uma revisão responsável também pergunta o que acontece quando alguém tenta uma ação que deveria ser recusada. É aí que a beleza do painel deixa de responder à pergunta.

O arquivo .env não ganhou poderes mágicos

Outro cenário merece atenção: alguém aprende que deve guardar configurações num arquivo .env, faz isso e considera o assunto resolvido. Só que a publicação foi configurada de uma forma que permite ao servidor entregar esse arquivo pela internet.

O nome do arquivo não cria uma barreira de acesso. Se ele contém credenciais e pode ser baixado, a organização das pastas não impediu a exposição.

Há uma advertência concreta na documentação do Laravel: servir a aplicação a partir da raiz do projeto pode expor configurações sensíveis. A orientação é direcionar o servidor para a estrutura pública correta. O mesmo guia recomenda desativar o modo de depuração em produção. Fonte: Laravel.

Existe ainda outra situação: o arquivo fica protegido, mas um segredo acaba incorporado ao JavaScript que o navegador recebe. No Vite, por exemplo, variáveis com prefixo VITE_ são expostas ao código cliente durante o build. A documentação alerta que elas não devem conter informações sensíveis. Fonte: Vite.

São dois caminhos diferentes para uma exposição. Em ambos, precisamos entender o que está sendo publicado. “Está no .env” é o começo da investigação, não uma garantia de segurança.

Ter ou não ter backend próprio não resolve a discussão

Também precisamos ser justos com a arquitetura. Uma API pode existir sem interface visual. Um site estático pode cumprir perfeitamente sua função. Uma aplicação pode usar serviços gerenciados para autenticação e dados sem manter um backend próprio.

O Supabase, por exemplo, documenta o acesso pelo frontend com chave publicável, RLS — regras que restringem o acesso às linhas do banco — e políticas adequadas. Já chaves secretas e service_role, que podem contornar essas restrições, devem permanecer fora do frontend. Fonte: Supabase.

Portanto, encontrar uma chave publicável no navegador não prova, sozinho, um vazamento. E contratar um serviço conhecido não prova que suas permissões foram configuradas corretamente.

A pergunta útil é bem direta: onde a regra de acesso é aplicada e o que comprova que ela funciona? Dá para responder com uma arquitetura enxuta. O que não dá é substituir a resposta por “o agente montou assim”.

A confiança também precisa passar por revisão

A pesquisa ajuda a olhar para esse comportamento com cuidado. Num estudo publicado na ACM CCS de 2023, 47 participantes resolveram cinco tarefas de programação relacionadas à segurança. O grupo assistido por IA produziu soluções inseguras com maior frequência em quatro tarefas e mostrou maior confiança na segurança do resultado. Estudo de Perry e colegas.

Era um experimento controlado com um modelo antigo, o codex-davinci-002. Não mede o Claude Code atual nem a proporção de aplicações inseguras em 2026.

Existe contraponto: outro estudo, apresentado na USENIX Security de 2023, avaliou 58 estudantes numa tarefa em C e encontrou impacto pequeno na segurança naquele contexto. Ferramenta, tarefa e forma de uso importam. Estudo de Sandoval e colegas.

Minha leitura é que precisamos tratar a confiança como hipótese até haver evidência. Você terminar uma conversa com a IA se sentindo seguro não equivale a ter verificado o sistema.

A própria documentação do Claude Code atribui ao usuário a responsabilidade de revisar a segurança do código e dos comandos propostos. As proteções para operar o agente e a segurança da aplicação resultante são assuntos distintos. Fonte: Anthropic.

Quando entram clientes, a brincadeira muda de tamanho

Na Oombe, trabalho com integrações de marketplaces. Nos projetos ligados à gestão pública, lido com serviços digitais destinados a pessoas reais. Essa vivência faz com que eu olhe para uma tela de cadastro e pense também em quem vai depender dela depois da demonstração.

Num cenário de falha, um comerciante poderia perder acesso a uma operação importante. Um cidadão poderia ter informações expostas. Uma equipe poderia ficar sem saber o que aconteceu e como recuperar o serviço. São exemplos de consequências possíveis, não relatos de incidentes nesses projetos.

Quem está começando talvez enxergue um formulário com cinco campos. Para quem preenche, ali podem estar nome, telefone, endereço e informações que não deveriam circular por aí.

No Brasil, o artigo 46 da LGPD prevê medidas técnicas e administrativas para proteger dados pessoais e determina que sejam observadas desde a concepção do produto ou serviço. O tamanho da operação exige avaliar o contexto; não autoriza ignorar a proteção. Fonte: LGPD.

A ANPD disponibiliza inclusive um guia para agentes de pequeno porte, com orientações sobre controle de acesso, cópias de segurança e atualização de sistemas. Há caminhos acessíveis para começar com responsabilidade. Fonte: ANPD.

Por isso, “vou colocar no ar e depois vejo a segurança” me preocupa tanto. Quando o “depois” chegar, alguém já pode ter confiado informações ao produto.

O que eu pediria antes do primeiro cliente

Eu começaria por uma conversa objetiva, acompanhada de demonstrações. Quem fez o sistema consegue responder a estas perguntas?

• O que foi construído? Quais componentes existem, onde executam e quem vai mantê-los?
• Quais dados são necessários? Para que são coletados, onde ficam e quem pode acessá-los?
• Como o acesso é limitado? Uma conta comum consegue fazer algo reservado ao administrador? Um cliente consegue alcançar os dados de outro?
• Onde ficam os segredos? O que é público por projeto e o que precisa permanecer protegido, inclusive na configuração da hospedagem?
• Como uma falha será percebida e corrigida? Há responsáveis, registros úteis e um caminho conhecido para recuperar o serviço?

Essas perguntas são um ponto de partida para revisão, não um certificado. O nível de verificação deve acompanhar o que a aplicação faz e o impacto de uma falha.

Minha recomendação para começar é reduzir o escopo. Faça um protótipo com dados fictícios, entenda uma funcionalidade de cada vez e peça revisão antes de colocar informações de terceiros no caminho. Na validação, demonstre também que operações proibidas são recusadas. A OWASP recomenda testes para a lógica de autorização. Referência.

Se faltar conhecimento, traga alguém com experiência para essa etapa. Isso pode significar uma revisão pontual, uma parceria ou mais tempo de estudo. Conseguir ajuda faz parte de assumir o projeto.

Para quem contrata, a mesma lógica vale: peça explicações e evidências proporcionais ao serviço. Um fornecedor sério deve conseguir discutir limitações sem transformar toda pergunta em “pode confiar”.

A pipa é linda. O escudo precisa aguentar

Quando comentei sobre esses sistemas bonitos e frágeis, usei uma imagem que ainda me parece perfeita: o Capitão América resolve trocar o escudo por uma pipa de papel de seda. A pipa é maravilhosa. Colorida, bem desenhada, ótima para a foto.

Até alguém precisar dela como escudo.

É assim que vejo um painel caprichado apoiado em permissões improvisadas. O visual merece elogio. Só que a confiança do cliente também exige uma estrutura capaz de sustentar o que foi prometido.

Se você entrou na programação pela IA, seja bem-vindo. Pergunte, experimente e aproveite essa porta aberta. Você não precisa sentir vergonha de ainda não saber; precisa reconhecer quando esse desconhecimento exige estudo ou ajuda antes de assumir uma entrega.

E quem já programa há anos também deve revisar o próprio trabalho. Tempo de carreira não elimina erro, assim como uma ferramenta poderosa não elimina a necessidade de critério.

Eu quero ver mais gente criando soluções úteis. Quero também que essas pessoas consigam explicar o que construíram, receber uma crítica técnica e cuidar de quem vai usar aquilo.

Na próxima vez que alguém mostrar um projeto, vou continuar começando com o elogio sincero:

Site bonito. Agora me mostra como você está protegendo quem vai usar.

---

Artigo de opinião técnica, apoiado em experiência pessoal e nas fontes primárias vinculadas ao longo do texto. Documentação consultada em 22 de outubro de 2026. Os exemplos foram simplificados para explicar os riscos, sem identificar clientes ou instituições.