← todos os posts
Segurança 9 min de leitura

Seu app pode estar público por padrão — e ninguém te avisou

380 mil apps feitos com IA abertos na internet, 5 mil vazando dado. A causa é o padrão de fábrica, não você. O teste de 2 minutos pra saber se o seu está.

"Quem nunca estudou isso não sabe o que não sabe."

É de um programador brasileiro, num fórum, falando de segurança em app feito com IA. Eu concordo com a frase e vou discordar da conclusão que costumam tirar dela. A conclusão costuma ser: então o problema é quem não estudou. A minha é outra: então o padrão de fábrica tinha que ser seguro. Porque quem não sabe o que não sabe não vai mudar uma configuração que nunca soube que existia.

Este post é sobre essa configuração.

Os números, e o que eles não provam

Em abril de 2026, a RedAccess — empresa israelense de segurança — varreu apps publicados em quatro plataformas: Lovable, Base44, Replit e Netlify. O resultado saiu na Axios em 7 de maio: 380 mil recursos publicamente acessíveis, e cerca de 5 mil deles vazando dado corporativo ou pessoal sensível. Entre os casos confirmados pela reportagem: conversas com pacientes de uma casa de cuidados infantis, escala de médicos e resumo de consulta de um hospital, e informações financeiras internas de um banco brasileiro.

Três coisas que esse número não diz:

  • 380 mil "acessíveis" não são 380 mil "vazando". Site é feito pra ser acessível. O problema são os 5 mil abertos e com dado dentro.
  • É varredura de quem está de fora, não auditoria. A Wix, dona da Base44, reclamou que a RedAccess não entregou as URLs. Quem mediu vende segurança.
  • Não é medição do seu app. É a forma da coisa — e a forma se repete.

O que a Axios registrou como causa é a informação mais útil do estudo inteiro: em algumas dessas plataformas, a configuração de privacidade deixa o app público a menos que o usuário mude na mão — e muitos desses apps estão indexados no Google. Ou seja, não precisa procurar. É só pesquisar.

Não foi você. Foi o padrão.

Quero ser exato sobre onde está a culpa, porque é isso que separa crítica de birra.

Não é a IA que escreveu o código. Não é o não-dev que "deveria ter estudado". É uma decisão de produto: alguém, numa plataforma, escolheu que projeto novo nasce aberto, porque aberto gera exploração, remix, vitrine — e vitrine é crescimento. Pra quem sabe o que "público" significa, é uma opção. Pra quem não sabe, é a porta escancarada com a chave na fechadura.

E não pega só iniciante. Em janeiro de 2026, a Moltbook — uma rede social de agentes de IA, feita por gente de tecnologia — foi ao ar com o banco de dados sem regra de acesso nenhuma. A Wiz, empresa de segurança em nuvem, documentou: a chave pública do banco estava no código que vai pro navegador, e com ela qualquer um lia e escrevia tudo — cerca de 1,5 milhão de chaves de acesso e 35 mil e-mails. Corrigido em horas depois do aviso. Mas foi ao ar assim.

Se gente da área publica assim, o problema não é falta de estudo. É que o caminho mais curto pra "funciona" passa por "aberto", e ninguém põe uma placa.

As três portas que a palavra "público" esconde

Aqui está o que nenhum aviso explica, e que faz a diferença entre o susto e a ação. "Meu app está público" pode significar três coisas diferentes, e cada uma se fecha num lugar.

Porta 1: o projeto. É o que você vê no editor — o código, o histórico de conversa com a IA, o que ainda não foi publicado. Na Lovable, isso é o que "projeto público" significava: qualquer pessoa com o link podia abrir, remixar e, com o remix, ler a conversa inteira e o código. Muita gente colou senha de serviço nessa conversa sem imaginar que ela era legível.

Porta 2: o app publicado. O endereço que você manda pro cliente. Site é público por natureza — a pergunta não é se ele abre, é o que aparece antes do login.

Porta 3: os dados. O banco atrás do app. Essa porta é independente das outras duas: o app pode exigir login na tela e o banco continuar respondendo pra qualquer um que pergunte direto. A documentação do Supabase é seca: uma tabela sem regra de acesso "pode ser lida e alterada por qualquer papel que tenha permissão sobre ela" — e o papel anônimo, o visitante sem login, costuma ter.

A própria documentação da Lovable separa a porta 1 da porta 2 em duas frases: "acesso ao projeto controla quem acessa o seu projeto no editor" e "acesso ao site controla quem visita o app publicado" — e "publicar não muda quem acessa o projeto". Guarde isso: fechar uma porta não fecha a outra.

Como cada plataforma trata isso hoje

Conferido na documentação oficial nesta semana, porque isso muda — e mudou.

Lovable. Até novembro de 2025, projeto novo no plano gratuito nascia público; só quem pagava escolhia "workspace" (privado pra sua equipe). Em 6 de novembro de 2025, projeto novo passou a nascer privado em todos os planos. Em dezembro, todo espaço de trabalho ganhou esse padrão. E em 22 de abril de 2026, projeto público deixou de existir: todos foram convertidos pra privado. Isso veio dois dias depois do fim de um incidente que a própria Lovable relatou: entre 3 de fevereiro e 20 de abril de 2026, um erro reintroduzido no servidor deixou o histórico de conversa e o código de projetos públicos acessíveis a qualquer usuário logado que tivesse o link. A empresa escreveu que "muitos usuários não perceberam que remixar um projeto público dava acesso ao histórico completo de chat e ao código-fonte". Crédito onde é devido: eles corrigiram o padrão, e disseram por quê.

Replit. A documentação de publicação diz, sem rodeio: "apps no seu espaço de trabalho pessoal têm Público como padrão". Quatro níveis existem — público, protegido por senha, só o workspace, só convidados. Em 6 de maio de 2026 (um dia antes da matéria da Axios), a publicação privada, que era de plano Pro e Enterprise, foi liberada pros planos Core e Starter. A opção existe pra mais gente agora. O padrão continua sendo aberto.

Base44. Três níveis: Público (qualquer um), Privado (só convidado), Workspace. A plataforma usa o que chama de "visibilidade inteligente": app que "se comporta como site público, como landing page ou portfólio, é automaticamente definido como Público sem exigir login". E um detalhe que importa pro seu bolso: "apps privados estão disponíveis só em planos pagos".

Netlify. Hospeda site. Site é aberto por definição; o que decide é o que você pôs dentro.

Resumo: uma corrigiu o padrão depois de se queimar; as outras deram a opção de fechar e deixaram a porta aberta como ponto de partida.

O teste da janela anônima

O que fazer hoje. Dois minutos, só o navegador.

Passo 1. Abra uma janela anônima (Ctrl+Shift+N no Chrome; Cmd+Shift+N no Mac). Anônima porque ela não sabe quem você é — ela é o visitante que nunca fez login.

Passo 2. Digite o endereço do seu app publicado. Olhe o que aparece antes de qualquer login. Uma tela de entrada, uma página de apresentação: ok. Uma lista de clientes, um painel, um relatório: está público, e não importa o que a tela de login diz depois.

Passo 3. Na mesma janela, cole o link do projeto (o que você abre pra conversar com a IA — não o endereço do app). Se pedir login, a porta 1 está fechada. Se abrir e mostrar o código ou a conversa, está aberta.

Passo 4. Vá ao Google e pesquise site: seguido do endereço do seu app — por exemplo, site:meuapp.lovable.app. O que aparecer ali é o que a internet inteira já encontra sem esforço. Se aparecer página que devia ser interna, você acabou de ver o seu app do jeito que a RedAccess viu.

Passo 5. Se o seu app usa Supabase (é o banco por trás da Lovable e de muita outra), abra o painel e vá no Table Editor. Qualquer tabela com o selo vermelho Unrestricted — sem restrição — é a porta 3 aberta. O que fazer com ela está aqui, passo a passo.

Encontrou porta aberta? Fecha cada uma no lugar dela:

  • Porta 1: Lovable — Configurações do projeto → visibilidade. Depois de abril de 2026 já não dá pra deixar público; se você está numa plataforma que ainda deixa, escolha "workspace" ou "privado".
  • Porta 2: Replit — na hora de publicar, troque o nível de acesso de Público pra "senha" ou "convidados". Base44 — Dashboard → Overview → App Visibility. Se o seu app tem dado de cliente, nenhum dos dois pode ficar em "público sem login".
  • Porta 3: ligar a regra no banco e testar.

E um aviso: este teste diz se o app inteiro está aberto pra quem não fez login. Ele não diz se um cliente logado consegue ver o dado de outro cliente logado — isso é outra falha, com outro teste, o dos dois usuários. Faça os dois. São portas diferentes.

A frase que resume o estudo

O CEO da RedAccess disse à Axios uma frase que eu acho verdadeira e assustadora ao mesmo tempo: "é realisticamente impossível educar as pessoas do mundo inteiro sobre segurança".

Ele está certo. Por isso a responsabilidade do padrão é de quem faz a plataforma — e a de conferir é sua. Não porque você deveria ter estudado, mas porque o cliente do outro lado é seu, e o nome no cadastro é o seu. A LGPD não pergunta quem gerou o código.

Cinco passos, dois minutos. Depois deles você sabe uma coisa que 380 mil apps não sabiam sobre si mesmos.

E essa é uma porta. O app tem mais: a que separa um cliente do outro, a chave que foi parar no navegador, o aviso de pagamento que chega duas vezes, o backup que nunca foi restaurado. Cada uma tem seu teste — e elas têm ordem. Fechar a porta da frente é onde se começa, não onde se termina.

Fontes