Segurança no Base44: o que a falha da Wiz significa para você

A segurança no Base44 virou assunto público em julho de 2025, quando pesquisadores da Wiz descobriram que um atacante conseguia se cadastrar em apps do Base44 que deveriam ser privados usando apenas o ID do app. A plataforma, que pertence à Wix, corrigiu o problema em menos de um dia. A falha estava na plataforma, não no app de um dono específico, e já foi fechada.

Isso não significa que o seu app está automaticamente seguro. A plataforma protege a infraestrutura e as contas. Você é responsável por quem pode ler quais dados no seu app. Sou um engenheiro brasileiro que trabalha com apps construídos com IA, e é assim que eu leria essa descoberta e o que eu verificaria.

O que os pesquisadores da Wiz encontraram no Base44 em julho de 2025?

Os pesquisadores da Wiz encontraram uma brecha de autenticação no Base44. Apps que deveriam ser privados podiam ser acessados por alguém que soubesse apenas o ID do app. Com esse ID, um atacante conseguia criar uma nova conta no app, mesmo que o dono o tivesse configurado como uma aplicação fechada e privada.

Por que um ID de app importava

Na maioria dos sistemas, um ID de app normalmente não é tratado como segredo. Identificadores assim podem aparecer em URLs, em requisições de rede ou no código do front-end. Um desenho em que saber o ID basta para passar pelos controles de cadastro transforma um identificador semipúblico em uma porta. É por isso que os pesquisadores levaram o caso a sério.

O que isso não significava

Isso não significa que apps do Base44 são inseguros por natureza, e não significa que todos os apps foram invadidos. Estou me baseando só no que foi divulgado publicamente: a falha existiu e foi corrigida. Eu não afirmaria mais do que isso, e desconfiaria de quem afirma.

Em quanto tempo a falha foi corrigida?

Segundo o que foi divulgado, o problema foi corrigido em menos de um dia. Para uma vulnerabilidade no nível da plataforma, é uma resposta rápida. A velocidade importa porque, a cada hora que uma falha fica aberta, mais pessoas podem encontrá-la.

Uma correção rápida não diz se alguém usou a falha antes de ela ser fechada. O que foi divulgado não diz se alguém usou a falha antes de ela ser fechada, então eu não presumiria nem uma coisa nem outra. Esse é um motivo para olhar a sua própria lista de usuários, o que explico mais abaixo.

O Base44 é seguro para usar agora?

O problema específico encontrado pela Wiz foi corrigido, então essa brecha está fechada. Se o seu app está seguro depende de como ele está configurado e do que ele faz.

Eu trataria o Base44, o Lovable, o Bolt e ferramentas parecidas da mesma forma: elas são boas para chegar a um primeiro rascunho que funciona. Código gerado por IA deve ser revisado como qualquer primeiro rascunho. O fato de a plataforma ser sólida não torna sólida a lógica dentro do seu app.

Um protótipo com dados de teste e sem pagamentos tem baixo risco. Um app com dados reais de clientes, logins e Stripe é outra história. Quanto mais está em jogo, mais vale uma revisão curta.

Quais partes da segurança ficam com o Base44 e quais são suas?

A segurança é uma responsabilidade compartilhada. A tabela mostra a divisão que uso quando explico isso para fundadores.

A descoberta da Wiz estava nas duas primeiras linhas, então a plataforma tinha que corrigir. Na minha experiência, os problemas que costumam pesar mais em apps construídos com IA ficam nas linhas de baixo, onde a responsabilidade é do dono.

O que os donos de apps no Base44 devem verificar hoje?

Você não precisa de uma auditoria completa para pegar a maior parte do risco. Quatro checagens focadas cobrem quase tudo antes de chegarem usuários reais.

1. Regras de acesso a dados

Para cada tipo de dado, pergunte: um usuário logado consegue ler ou editar os registros de outro usuário? Teste. Crie duas contas e tente abrir os dados da segunda a partir da primeira. Em apps do Lovable, row level security fraca no Supabase tem sido um padrão recorrente, e a mesma pergunta vale para qualquer construtor.

2. Chaves expostas

Abra o seu app no navegador, olhe as requisições de rede e o código-fonte da página e procure qualquer coisa que pareça uma chave secreta. Chaves públicas não são problema. Chaves secretas de pagamento, email ou serviços de IA precisam ficar em um servidor, nunca no navegador. Se alguma vazou, troque-a.

3. Confirmação de pagamento

Não confie no navegador para dizer que um pagamento deu certo. O seu app deve confirmar o pagamento por meio de eventos do Stripe verificados no servidor. Verifique o que acontece se um evento chega duas vezes, chega atrasado ou nunca chega. Scanners genéricos não pegam isso porque é lógica de negócio, não um padrão de vulnerabilidade conhecido.

4. Backups

Descubra onde os seus dados ficam e se você consegue restaurá-los. Um backup que você nunca restaurou é um palpite. Exporte uma cópia dos dados que você não pode se dar ao luxo de perder.

Revise também a sua lista de usuários

Por causa da descoberta da Wiz, revise os usuários cadastrados em um app privado. Remova contas que você não reconhece e verifique se alguma delas mexeu em dados. Isso leva minutos e diz algo concreto.

Quando você deve sair do Base44?

Ficar às vezes é a melhor decisão, e eu não empurro as pessoas a sair por padrão. Migrar custa tempo e cria os seus próprios riscos.

Motivos para ficar

• Você está validando uma ideia com poucos usuários e sem dados sensíveis.
• O app é simples e você consegue passar nas quatro checagens dentro do construtor.
• Você não tem um engenheiro para manter o código que passaria a ser seu depois de sair.

Motivos para sair

• Você precisa de controle sobre hospedagem, logs, backups ou onde os dados ficam armazenados.
• A sua lógica ficou maior do que o construtor consegue lidar com confiabilidade, como pagamentos ou permissões complexos.
• Clientes ou parceiros pedem evidências de segurança que você não consegue produzir na plataforma.
• A performance com tráfego real está virando um problema.

Se você for sair, a ordem que prefiro é: corrigir primeiro os problemas de maior risco no código existente, depois exportar para o GitHub e para a sua própria hospedagem, e só reescrever o que estiver realmente quebrado. Uma reescrita completa raramente é o primeiro passo. Confira quais opções de exportação o seu construtor oferece, porque elas variam entre as ferramentas. O código do Lovable, por exemplo, pode ir para o GitHub e para a sua própria hospedagem.

Quer uma segunda opinião sobre o seu app?

Se você tem um app no Base44 a caminho de usuários reais, mande um email para me@filipeeduardo.dev com o link e uma nota sobre o que ele faz, e eu digo o que verificaria primeiro.