Como proteger um app feito com vibe coding antes de compartilhar
Resposta rápida
Antes que os colegas usem um app que você criou com IA, verifique quatro coisas primeiro: ninguém passa sem o login da empresa, só as contas da sua empresa entram, não há chaves no código que roda no navegador e o banco de dados não pode ser lido sem passar pelo app. Depois verifique quem pode fazer o quê dentro dele, e quem fica responsável quando você sair.
A maioria dos vazamentos de apps feitos com IA não vem de ataques espertos. São portas abertas: um link público, um banco de dados com as regras desligadas, uma chave na página. Este checklist é para quem criou o app e para a pessoa de TI que vai revisá-lo. Cada item diz o que dá errado, como verificar em palavras simples, e o que o TeamOnly resolve e o que ainda fica com você.
Última atualização Escrito pelo TeamOnly. Hospedamos apps internos criados com IA, e cada item diz com honestidade onde ajudamos e onde não.
01Por que isso importa
O que dá errado com apps feitos com IA
As ferramentas de IA são boas em fazer um app funcionar. São menos cuidadosas com para quem mais ele funciona. Três descobertas dos últimos dois anos mostram o padrão.
380.000
recursos acessíveis publicamente encontrados no Lovable, Base44, Netlify e Replit pela empresa de segurança Red Access em maio de 2026. Cerca de 5.000 tinham dados sensíveis de empresas, e muitos estavam indexados pelo Google.
170 de 1.645
apps do Lovable verificados em março de 2025 deixavam qualquer pessoa ler ou alterar dados no banco de dados Supabase sem entrar, porque as regras de acesso ao banco de dados não existiam ou estavam erradas (CVE-2025-48757).
205.474
nomes de pacotes inventados sugeridos por 16 modelos de IA em 576.000 amostras de código, em um estudo de 2025. Atacantes podem publicar pacotes com esses nomes e esperar alguém instalar.
Nenhum desses casos precisou de um atacante esperto. As portas estavam abertas. Isso é uma boa notícia: portas abertas são fáceis de verificar, e você não precisa ler código para isso.
Faça na ordem. As primeiras deixam estranhos de fora, as seguintes pegam erros dentro da empresa.
Nada carrega antes do login da empresa
O que dá errado
As ferramentas de IA costumam criar a tela de login como uma página do app. O resto do app, e a API dele, continuam respondendo a quem pula essa página ou chama a API diretamente. A Red Access encontrou apps de empresas que davam acesso de admin a qualquer pessoa que chegasse ao endereço.
Verifique você mesmo
Abra o app em uma janela anônima. Você deve ver uma tela de login e nada mais. Depois pergunte à sua ferramenta de IA: “Liste todas as rotas da API e me diga quais funcionam sem login.” A resposta deve ser nenhuma.
No TeamOnly
Resolvido. Cada requisição a cada app é verificada antes de qualquer parte do seu código rodar, inclusive chamadas à API, que recebem um 401 sem sessão. Não existe opção para deixar um app público.
Só as contas da sua empresa entram
O que dá errado
“Entrar com o Google” deixa qualquer conta Google entrar por padrão, inclusive um Gmail pessoal. O parâmetro hd do Google só restringe o seletor de contas, e o Google avisa para não confiar nele porque a requisição pode ser alterada. O domínio precisa ser verificado no servidor.
Verifique você mesmo
Tente entrar com uma conta pessoal do Gmail ou do Outlook. Você deve ser barrado. Pergunte à sua ferramenta de IA onde o servidor verifica o domínio do e-mail, e se ele verifica o token assinado do Google ou um valor que o navegador mandou.
No TeamOnly
Resolvido. Os colegas entram com a conta Google de trabalho, a conta Microsoft de trabalho ou um código enviado para o e-mail corporativo. O domínio no token de login verificado é comparado com os domínios da sua empresa, e contas pessoais são recusadas.
Só as pessoas certas dentro da empresa
O que dá errado
Um app com salários, avaliações ou dados de clientes é compartilhado com a empresa toda porque esse era o padrão. Ou a IA cria a própria lista de permitidos no código, que ninguém atualiza.
Verifique você mesmo
Pergunte: todo mundo na empresa deveria ver esses dados? Se não, anote os nomes de quem deveria, e verifique se alguém fora dessa lista é barrado.
No TeamOnly
Resolvido, você escolhe. O acesso é a empresa toda ou uma lista de nomes, configurado no painel ou com npx teamonly access only priya@acme.com. Ele é verificado em cada requisição, então remover alguém vale em até um minuto.
Nem em link público, nem nos resultados de busca
O que dá errado
Alguns criadores de apps publicam em um endereço público a não ser que você escolha privado. Apps públicos são encontrados: a Red Access relatou que muitos dos apps de empresas expostos estavam indexados pelo Google e outros buscadores.
Verifique você mesmo
Busque no Google site: seguido do endereço do seu app. Verifique a configuração de visibilidade do projeto na plataforma onde você o criou. Se estiver público, mude isso antes de qualquer outra coisa.
No TeamOnly
Resolvido. Os apps ficam em yourapp.yourcompany.teamonly.app atrás da tela de login. Cada resposta, inclusive a tela de login, diz aos buscadores para não indexar, e a tela de login mostra só o nome do app e as formas de entrar.
Nenhuma chave no código que roda no navegador
O que dá errado
As ferramentas de IA colocam chaves de API no código React ou em variáveis que começam com VITE_ ou NEXT_PUBLIC_. Tudo o que vai para o navegador pode ser lido por qualquer pessoa que abrir o app. O Supabase diz que a chave secreta nunca deve ficar em um navegador, porque ela ignora todas as regras do banco de dados.
Verifique você mesmo
Pergunte à sua ferramenta de IA: “Existe alguma chave, token ou senha no código do front-end, em uma variável VITE_ ou em um arquivo .env commitado?” No navegador, abra as ferramentas de desenvolvedor e busque key, secret e sk_ nos arquivos carregados. Se uma chave já ficou exposta alguma vez, troque no serviço que a emitiu.
No TeamOnly
Resolvido em parte. As chaves ficam guardadas com npx teamonly secrets set NAME, fora do código, e só o código de servidor do seu app consegue ler. As instruções que o TeamOnly adiciona dizem à sua ferramenta de IA para nunca usar chaves VITE_. Nada impede você de colar uma chave no código, então verifique mesmo assim.
O banco de dados não pode ser lido por fora do app
O que dá errado
No Supabase e em serviços parecidos, o navegador fala direto com o banco de dados e as regras de acesso (row-level security) decidem o que ele pode ver. Quando essas regras estão desligadas ou erradas, qualquer pessoa com a chave pública pode ler ou alterar tabelas inteiras. Foi isso que encontraram no Lovable.
Verifique você mesmo
No Supabase, abra Advisors e depois Security Advisor. Qualquer erro “RLS disabled in public” significa uma tabela que qualquer pessoa pode ler. Ter uma regra não basta: entre como um colega comum e tente abrir o registro de outra pessoa.
No TeamOnly
Resolvido para quem é de fora. O banco de dados de cada app não tem endereço próprio na internet. Ele só é alcançado pelo código de servidor do seu app, depois do login. Quais linhas cada pessoa logada pode ver ainda é algo que o código do seu app precisa acertar (veja a verificação 8).
Os dados de cada app separados
O que dá errado
Vários apps compartilham um banco de dados ou um bucket de armazenamento porque era mais rápido. Aí uma chave ou um bug em um app abre todos.
Verifique você mesmo
Pergunte: algum outro app usa o mesmo banco de dados, armazenamento ou chaves que este? Se sim, o app mais fraco decide o quanto todos são seguros.
No TeamOnly
Resolvido. Cada app recebe o próprio banco de dados, armazenamento de arquivos e segredos na primeira publicação, e o cookie de sessão fica preso ao próprio endereço. Os apps não alcançam os dados uns dos outros.
Quem pode fazer o quê, verificado no servidor
O que dá errado
A IA esconde o botão Aprovar da maioria das pessoas mas deixa a rota de aprovação aberta para qualquer pessoa logada. Ou o servidor confia em um papel ou e-mail que o navegador manda. Controle de acesso quebrado é o número um do OWASP Top 10. Entrada sem verificação é parente disso: um valor negativo, uma consulta SQL montada a partir de uma caixa de texto.
Verifique você mesmo
Entre como um colega comum e tente fazer o que só gerentes deveriam fazer. Pergunte à sua ferramenta de IA: “Para cada rota da API, quem pode chamá-la e em que parte do servidor isso é verificado? Todas as consultas ao banco de dados usam placeholders?”
No TeamOnly
Resolvido em parte. Seu app recebe a pessoa verificada (ctx.user) e os papéis que você distribui no painel (ctx.user.roles), e cabeçalhos de identidade falsos são removidos. As instruções dizem à sua ferramenta de IA para usar placeholders nas consultas e verificar a entrada no servidor. Verificar o papel em cada rota é código do seu app. O TeamOnly não revisa isso.
Cada pacote é real e necessário
O que dá errado
As ferramentas de IA às vezes sugerem pacotes que não existem. Atacantes publicam pacotes com esses nomes, então instalar um deles roda o código de um estranho dentro do seu app.
Verifique você mesmo
Abra o package.json. Procure no npmjs.com qualquer nome que você não reconheça: um pacote real tem histórico, um repositório de código vinculado e downloads constantes. Rode npm audit antes de publicar, e remova pacotes que o app não usa mais.
No TeamOnly
Não resolvido. O TeamOnly não analisa pacotes. Um app só alcança os próprios dados e chaves, o que limita o que um pacote ruim pode tocar, mas dentro desse app ele ainda poderia ler tudo.
Um registro de quem mudou o quê
O que dá errado
Algo é aprovado, excluído ou alterado e ninguém sabe dizer quem fez. Apps feitos com IA raramente guardam histórico, a não ser que você peça.
Verifique você mesmo
Peça à sua ferramenta de IA para registrar quem criou e quem alterou por último cada registro, e quando, e para manter uma tabela de histórico de aprovações e exclusões. Teste: altere um registro e procure seu nome nele.
No TeamOnly
Resolvido em parte. O painel mostra cada publicação de cada app, com quem publicou e quando, e logs ao vivo. Os logs são ao vivo, não ficam guardados. Logs de auditoria de logins e mudanças de acesso estão no plano Business, configurados com você. O histórico dentro do app (quem aprovou uma despesa) é trabalho do seu app.
Um responsável, um backup e um plano para quem sai
O que dá errado
O criador sai e o app continua rodando na conta pessoal dele, ou para quando o cartão é cancelado. Ou uma mudança ruim apaga uma tabela e não existe cópia.
Verifique você mesmo
Anote quem é o responsável pelo app e quem assume depois. Guarde o código em um repositório Git da empresa. Peça à sua ferramenta de IA para adicionar uma exportação CSV das tabelas principais, e teste.
No TeamOnly
Resolvido em parte. Os apps pertencem à sua empresa, e os admins podem passar um app para um novo responsável. Desativar a conta de trabalho de alguém impede novos logins. Quem já entrou continua dentro até a sessão acabar, e os admins escolhem quanto tempo isso dura, de 8 horas a 30 dias. Hoje não há botão de backup nem de exportação no painel, então inclua a exportação no app.
03Imprima
A verificação de um minuto
Onze perguntas de sim ou não. Qualquer “não” é a próxima coisa a corrigir.
Antes de compartilhar este app
Uma janela anônima mostra um login da empresa e nada mais.
Uma conta pessoal do Gmail ou do Outlook é barrada.
Só as pessoas que precisam desses dados conseguem abrir.
Uma busca site: pelo endereço do app não encontra nada.
Nenhuma chave, token ou senha está no código do navegador ou no repositório.
O banco de dados não pode ser alcançado sem passar pelo app.
Os dados e as chaves deste app não são compartilhados com nenhum outro app.
Um colega comum não consegue fazer o que só gerentes deveriam fazer.
Cada pacote do package.json é real e ainda é usado.
Os registros mostram quem os criou e alterou.
Outra pessoa sabe que é responsável por este app se eu sair, e os dados podem ser exportados.
Quinze minutos com o criador, tela compartilhada. Você está verificando a configuração, não lendo cada linha de código.
Onde ele fica e quem consegue acessar
Pegue o endereço. Abra a partir de um dispositivo sem login, e de uma conta pessoal. Pergunte qual plataforma hospeda o app e de quem é a conta que paga. Uma conta pessoal é a primeira coisa a mudar.
Quais dados ele guarda
Pergunte o que entra e de onde vem. Dados pessoais de clientes, dados de pagamento, dados de saúde ou senhas de outros sistemas aumentam a exigência, e podem significar que o app deve ficar restrito a uma lista de nomes.
Onde estão as chaves
Liste cada serviço externo que o app chama. Cada chave deve ficar nas configurações de segredos da hospedagem, limitada ao que o app precisa, e não compartilhada com outros apps. Troque qualquer chave que já tenha estado no código ou em um chat.
Quem pode fazer o quê
Peça ao criador para entrar como usuário comum, ou peça a um colega, e testem as ações de admin. Peça ao criador que a ferramenta de IA dele liste cada rota da API e onde ela verifica o papel. Falhas aqui se corrigem no código do app.
Pacotes e código
Olhem juntos o package.json e rodem npm audit. Peça que o código fique em um repositório Git da empresa, não só no notebook do criador.
O responsável, e o dia em que ele sair
Registre o app, o responsável, um responsável reserva, os dados e os usuários na sua lista de apps. Combinem o que acontece quando o responsável sair. O guia de apps de shadow AI tem uma política de uma página que você pode copiar.
É seguro compartilhar apps feitos com vibe coding com os colegas?
Pode ser. Os problemas comuns estão em onde o app fica e como foi configurado: um link público, nenhum login de verdade, chaves no navegador, regras do banco de dados desligadas. Cada um se verifica em poucos minutos. Rode o checklist desta página antes de mandar o link.
Qual é o maior risco de segurança em um app feito com vibe coding?
Dados que qualquer pessoa alcança sem entrar. Isso costuma acontecer de duas formas: o app está em um link público sem login na frente, ou o banco de dados responde requisições diretamente e as regras de acesso estão desligadas (row-level security no Supabase). As duas são de configuração, não de a IA escrever código ruim.
É seguro colocar a chave anon do Supabase no navegador?
A chave anon ou publishable foi feita para ficar no navegador, mas só porque o row-level security limita o que ela alcança. Se o row-level security estiver desligado em uma tabela, qualquer pessoa com essa chave pode ler e alterar a tabela. A chave secreta ou service_role nunca deve ficar no navegador: ela ignora todas as regras.
“Entrar com o Google” limita um app à minha empresa?
Sozinho, não. Por padrão qualquer conta Google pode entrar, inclusive um Gmail pessoal. O parâmetro hd do Google só restringe o seletor de contas, e o Google diz para não confiar nele. O servidor do app precisa verificar o domínio no token de login verificado em cada requisição.
Como verifico se meu app está indexado no Google?
Busque no Google site: seguido do endereço do seu app, por exemplo site:myapp.lovable.app. Se aparecerem páginas, o app é público e está indexado. Deixe o app privado ou coloque atrás de um login da empresa, e depois peça ao Google para remover as páginas com a ferramenta Remoções do Search Console, se o domínio for seu.
Devo pedir à minha ferramenta de IA para escrever código seguro?
Sim, e é melhor dar instruções permanentes do que pedir uma vez. Um arquivo de regras no projeto (CLAUDE.md, AGENTS.md ou uma regra do Cursor) diz à ferramenta onde ficam as chaves, como escrever consultas ao banco de dados e onde verificar os papéis. npx teamonly init adiciona isso nos apps do TeamOnly. Mesmo assim, faça as verificações você: as instruções reduzem os erros, não acabam com eles.
O TeamOnly analisa o código do meu app em busca de problemas de segurança?
Não. O TeamOnly coloca um login da empresa na frente de cada app, mantém separados os dados e as chaves de cada app e deixa os apps fora dos buscadores. Ele não revisa seu código, não analisa seus pacotes nem verifica as regras dentro do seu app. Esses itens do checklist continuam com você.
O que a TI deve verificar antes de aprovar um app feito com IA?
Onde ele está hospedado e quem consegue acessá-lo, como o login é restrito, onde estão as chaves, quais dados ele guarda, quem é o responsável e o que acontece quando essa pessoa sai. A seção “Para TI” desta página é uma revisão curta que você faz em 15 minutos com o criador.
Publique com um comando e o app fica atrás do login da sua empresa, fora dos buscadores, com o próprio banco de dados e segredos. Teste grátis por 14 dias, sem cartão.