Reeve Noções de segurança
Scan de segurança do Base44: o que só ele enxerga
O scan de segurança do Base44 verifica sete tipos de problema por dentro. Esta é a metade que ele lê e mais ninguém, e a metade que ele nunca olha.
Em resumo
- O scan de segurança do Base44 roda por dentro do seu projeto e verifica sete tipos de problema, das regras de acesso aos seus dados até as bibliotecas de que o app depende. Está incluído em todos os planos, e uma das sete verificações só roda a partir do Builder.
- Num app Base44 ele é o único scan capaz de responder ao que as pessoas realmente querem dizer com "meu app está seguro": se um estranho consegue ler seus dados. Avaliamos 5.442 apps Base44 no ar e conseguimos perguntar a 2.
- O que ele não tem motivo para ler é a página que seus visitantes baixam. Em 95 desses 5.442 apps havia ali uma chave de API do Google.
Você abre o Dashboard do seu app Base44, clica em Security, aperta Run Security Scan e alguns segundos depois volta uma lista. Ou não volta nada. De um jeito ou de outro você está com um resultado na mão e se perguntando se aquilo era a verificação inteira.
A maioria dos textos sobre isso conta ao contrário. O argumento de sempre diz que um scan rodado de dentro do seu projeto não enxerga o que a internet enxerga, então o de fora é o confiável. No Base44 é o inverso na metade que importa: o scan de segurança do Base44 é a única coisa capaz de verificar se um estranho consegue ler seus dados, e nós conseguimos mostrar que não conseguimos. Tentamos em 1.466 apps Base44 e obtivemos resposta de dois.
Então isto é uma divisão de trabalho. Um scan trabalha dentro do prédio. O outro fica na calçada e lê o que é entregue pela frente. Os dois valem a pena, e no Base44 o de dentro faz a metade mais pesada.
O que o scan de segurança do Base44 verifica?
Sete tipos de problema, lidos de dentro do seu projeto. Ele nunca busca seu endereço publicado.
| O que ele verifica | O que isso quer dizer | Planos |
|---|---|---|
| Data permission issues | Uma tabela de dados sem regras de acesso, ou pessoas com mais acesso do que deveriam ter | Todos |
| Exposed secrets | Chaves de API, senhas ou tokens deixados num lugar que os visitantes do app alcançam | Todos |
| Unauthenticated backend functions | Algo nos bastidores entregando dados sem checar quem pergunta. Intitulado "Anyone can run this function" | Todos |
| Credit protection | Suas funções de IA, imagem ou e-mail alcançáveis de fora do seu app, de modo que outra pessoa gaste seus créditos | Todos |
| App dependencies | Uma biblioteca de terceiros com falha conhecida, junto da versão para a qual migrar | Todos |
| Code vulnerabilities | Padrões no seu próprio código: checagens de acesso que faltam, tratamento descuidado do que alguém digitou | A partir do Builder |
| Security header recommendations | Duas proteções do navegador, a incorporação em iframe e os recursos do navegador que você não usa | Todos |
Tudo isso foi lido em 10 de outubro de 2026 na documentação do próprio Base44,
nas páginas Running a security scan e Base44 security: An overview. Três
coisas de lá vale conhecer antes de confiar no resultado:
- O scan nunca aplica uma correção sozinho. Você aperta Fix e o Base44 escreve a mudança no chat de IA do seu app com um checkpoint antes dela, de modo que uma correção que quebre algo pode ser desfeita a partir do chat.
- O botão Fix with AI numa função não autenticada rejeita qualquer chamada sem usuário logado. O Base44 diz na mesma frase que isso pode quebrar uma página feita para visitantes deslogados, um webhook ou uma integração que chame essa função. Teste esses caminhos depois.
- Ele avisa na publicação e não te impede. O painel de publicação mostra um status de Security, e o Base44 o descreve como um aviso que não impede você de publicar.
O que só ele enxerga
Se as pessoas que usam seu app conseguem alcançar dados que não são delas. Num app Base44, nada fora da plataforma consegue verificar isso.
Na maioria dos builders seu app conversa com o banco de dados direto do navegador do seu visitante. Com isso o banco tem um endereço público, sua página carrega esse endereço e qualquer um pode tirá-lo dali e começar a perguntar. Se ele recebe respostas depende de um ajuste tabela por tabela que a maioria dos donos nunca abriu. Um app Base44 manda suas requisições pelo Base44, então não há endereço nenhum na rua para alguém tentar.
A medição é desequilibrada o bastante para resolver a questão. 1.466 dos 5.442 apps Base44 que avaliamos citam um projeto Supabase em algum ponto da página. Nossa verificação de Row Level Security obteve resposta utilizável de 2 deles. No Lovable, onde o banco responde direto à rua, responderam 3.553 de 6.535. No Bolt, 35 de 267.
Dois apps não são uma taxa e não vamos imprimir nenhuma. O que o número resolve é quem pode olhar: num app Base44 as regras de acesso aos seus dados são legíveis na página Security do seu próprio painel e em nenhum outro lugar. O levantamento completo de como 5.442 apps Base44 pontuaram tem os demais números.
Por que seu app publicado ainda pode estar carregando uma chave
Porque o scan lê seu projeto e seus visitantes baixam um arquivo. Quatro coisas da documentação do próprio Base44 separam as duas:
- A versão publicada pode ser mais antiga do que a que o scan leu. O achado de credit protection do Base44 tem um estado exatamente para isso, e o aviso diz "Publish changes before protecting credits" quando seu app no ar ainda roda uma versão anterior.
- O status na publicação é um aviso. Risks found abre a página Security, e você pode publicar mesmo assim.
- Um achado que você ignora não volta. Achados ignorados vão para uma seção própria no fim da lista e, nas palavras do Base44, não reaparecem no scan seguinte. Uma lista limpa pode significar que alguém descartou o achado em junho.
- A metade do código precisa de um plano pago. Code vulnerability scanning roda a partir do Builder, assim como a integração opcional com o Wiz, que acrescenta análise estática usando seu próprio tenant do Wiz.
Da calçada, essa diferença tem tamanho. Dos 5.442 apps Base44 que avaliamos, 95 serviam uma chave de API do Google na página, 11 tinham algo com formato de senha ou de token, um tinha uma chave restrita do Stripe e outro uma chave secreta do Stripe. A verificação de credenciais respondeu nos 5.442 apps, então são contagens e não uma amostra.
Esses 95 são uma fatia menor que a dos vizinhos, e vale dizer com clareza: na mesma varredura, 727 de 18.563 apps Lovable e 200 de 3.050 apps Replit carregavam uma chave de API do Google. Nessa medição os apps Base44 estão mais quietos que os construídos ao lado.
É também o achado desta lista com mais chance de estar tudo bem. O Google emite um único tipo de chave de API e espera vê-la no navegador; o que decide se um estranho consegue acumular uma fatura com ela é se você a restringiu ao seu próprio domínio, e essa restrição mora no console do Google, não no seu app. O que verificar numa chave do Google encontrada na sua própria página são os dois ajustes a ler.
Se você prefere ver a lista inteira do que seu app Base44 publicado entrega, nosso scan gratuito lê seu endereço no ar e relata o que consegue ver de fora. Leva cerca de 20 segundos e não pede conta: escanear seu app de graça.
A verificação dessa lista com que ninguém conta
Alguém chamando as funções pagas do seu app direto, sem passar pelo seu app.
O Base44 chama isso de credit protection, e o achado aparece quando uma função sua que usa IA, geração de imagem ou e-mail é alcançável de fora do seu app. A documentação deles é direta sobre a consequência: quem a encontrar pode executá-la e gastar seus créditos de integração. Ela é classificada como High e, dependendo do seu app, a correção é um único botão Fix que restringe essas funções sem mexer no seu próprio acesso, ou um Resolve with AI que move as chamadas para o seu backend.
Isso é do tipo que um scan de dentro faz bem e um de fora não tem como testar honestamente. Descobrir se alguém consegue executar sua função de e-mail de graça exigiria executá-la, então nosso scan deixa essa para o Base44 e relata o que consegue ler sem gastar nada que seja seu.
O que nenhum dos dois scans verifica
Três coisas, e a última é a única desta página que não dá para consertar depois.
Seu certificado e seu domínio, se o app está no seu próprio endereço. Um app
Base44 num endereço base44.app herda os do Base44. Mude-o para um domínio que
você comprou e as datas de renovação passam a ser suas, que é
o jeito mais silencioso de um app que funciona apagar.
Arquivos num bucket do Supabase Storage que você conectou. Dos 1.466 apps Base44 que citam um projeto Supabase, nossa verificação de buckets conseguiu responder em 5. A mesma parede que esconde o banco esconde o bucket, e a verificação de acessos do Base44 cobre as tabelas que ele gerencia, não um bucket num projeto que você mesmo conectou.
Se existe uma cópia dos seus dados. Isso nenhum scan de nenhum lado da parede verifica, porque não é uma propriedade do seu app. É uma propriedade do que você montou em outro lugar, e decide se uma migração que deu errado ou um agente com acesso ao banco termina numa restauração ou num e-mail para seus usuários. O dia em que um agente de IA apagou um banco de dados de produção mostra como a segunda opção se lê.
Manter as duas metades cobertas depois de publicar
Rode os dois de novo depois de qualquer mudança. Um resultado da semana passada descreve o app da semana passada, e no Base44 publicar é um botão, então uma tabela criada hoje de manhã ou uma chave colada à meia-noite está no ar assim que você aperta.
O Reeve Monitor passa as nove verificações de fora de novo por você:
- as nove verificações a cada hora, em até três apps
- se o app responde, a cada 60 segundos
- uma mensagem quando um resultado muda, para que um achado novo não espere você olhar
- um relatório mensal do que foi visto
Se o seu app Base44 guarda os dados no seu próprio projeto Supabase, o Reeve Care mantém uma cópia deles:
- uma cópia criptografada do seu banco Supabase toda noite, guardada onde seu projeto não alcança
- cada cópia verificada antes de contar, contando as linhas de cada tabela
- uma restauração em um clique quando você precisar
- seus arquivos enviados também, assim que você conectar uma credencial de Storage
- tudo o que o Monitor faz
Os dois estão na página de preços, que às vezes está abaixo do valor de tabela daqui e nunca acima.
O que fazer hoje
O que fazer
- Rode o scan em Dashboard → Security antes da próxima publicação e leia os achados antes de apertar Fix all issues. A correção de uma função não autenticada pode trancar uma página que você queria aberta.
- Olhe a seção Ignored no fim da lista. Um achado que alguém ignorou meses atrás continua ignorado hoje.
- Se seu app gasta créditos de integração com IA, imagens ou e-mail, leia primeiro o achado de credit protection. É o da lista que custa dinheiro sozinho.
- Escaneie depois o endereço publicado por fora, porque o app no ar pode ser uma versão anterior à que o scan leu.
- Guarde uma cópia dos seus dados onde seu app não alcança, se você conectou seu próprio projeto Supabase. Nenhum dos dois scans consegue dizer se ela existe.
Comece pela seção Ignored, leva segundos e é o único lugar em que um relatório limpo pode estar escondendo um achado de verdade. Se quiser a versão em linguagem simples de tudo o que dá para verificar de fora num app Base44, temos um guia para apps Base44.
Perguntas frequentes
O Base44 verifica meu app em busca de problemas de segurança?
Sim. Abra o editor do seu app, clique em Dashboard, depois em Security e depois em Run Security Scan. Ele verifica sete tipos de problema: as regras de acesso aos seus dados, credenciais expostas, funções de backend que respondem sem checar quem está perguntando, funções que gastam seus créditos de integração, bibliotecas de terceiros com falhas conhecidas, padrões no seu próprio código e dois cabeçalhos de segurança do navegador. Cada achado vem com uma correção sugerida que você pode aplicar, e o scan não aplica nenhuma por conta própria. Está incluído em todos os planos, inclusive no gratuito, mas a metade que lê o código só roda a partir do Builder. Lido em 10 de outubro de 2026.
O scan de segurança do Base44 é suficiente?
Ele é o único scan capaz de verificar a parte mais importante de um app Base44, porque seus dados ficam atrás do Base44 e não num endereço público. O que ele não tem motivo para fazer é buscar sua página publicada e ler o que saiu nela. Avaliamos 5.442 apps Base44 no ar: a pergunta sobre o banco de dados teve resposta em 2 deles, e 95 serviam uma chave de API do Google na página. Rode o scan de dentro antes de publicar e um de fora depois.
Por que um scanner externo não consegue verificar meu banco de dados do Base44?
Porque não há nada na rua em que bater. Na maioria dos builders seu app conversa com o banco de dados direto do navegador do visitante, então o banco tem um endereço público, sua página carrega esse endereço e qualquer um pode tirá-lo dali e fazer perguntas. Um app Base44 manda suas requisições pelo Base44. Dos 1.466 apps Base44 que avaliamos e que citam um projeto Supabase em algum ponto da página, nossa verificação de Row Level Security obteve resposta utilizável de 2. No Lovable, onde o banco responde direto à rua, responderam 3.553 de 6.535.
O que um scan externo encontra que o Base44 não encontra?
O que seus visitantes recebem agora. O Base44 lê o projeto que está no seu editor, e quatro coisas da documentação deles separam isso do app no ar: a versão publicada pode ser mais antiga do que a que o scan leu, o scan avisa na publicação sem bloqueá-la, um achado ignorado uma vez não volta, e a análise do código precisa do plano Builder. Nos 5.442 apps Base44 que avaliamos, 95 tinham uma chave de API do Google na página, 11 tinham algo com formato de senha ou de token, um tinha uma chave restrita do Stripe e outro uma chave secreta do Stripe.
Devo rodar os dois?
Eles respondem a metades diferentes, então um não substitui o outro. Rode o scan do Base44 na página Security antes de publicar, leia os achados antes de apertar Fix all issues e depois verifique o endereço publicado por fora. Um scan externo leva cerca de 20 segundos e não pede conta.