A segurança dos apps vibe-coded em 2026

Seis números que contam a história

Estes seis números são o relatório. Tudo o que vem depois deles é a base sobre a qual cada um se apoia, e como chegamos até ela.

Os padrões de fábrica das plataformas falham em quase todo lugar, e a maioria dessas falhas é moderada. O que só quem construiu o app pode mudar falha bem menos, e é isso que põe o dado de outra gente na internet aberta.

Que nota esses apps tiram, de A a F

O Reeve dá nota a um app como um boletim escolar. Os descontos saem de cem e são ponderados pela gravidade. Depois, o achado mais grave impõe um teto: com um achado crítico o app não passa de D, e com um achado alto não passa de C.

A maioria dos apps cai em A ou B. A faixa de D e F é pequena. São os apps em que um estranho já consegue ler as linhas de outra pessoa.

O que verificamos, e quantos apps falharam em cada

Cada verificação faz uma pergunta sobre o app visto de fora, e cada uma é contada sobre os apps em que obteve resposta. Um app que a verificação não conseguiu alcançar fica fora da base daquela verificação, em vez de entrar como limpo. Sobre esses o scan diz que não conseguiu verificar, e esta página faz o mesmo.

Duas linhas parecem mais assustadoras do que são. Cabeçalhos de segurança são instruções que a plataforma de hospedagem manda para o navegador, e um deles faltando deixa um tipo de ataque com um obstáculo a menos pela frente. Um source map publicado é o código original do app parado ao lado da versão compilada: mostra a um invasor onde procurar, e por si só não entrega nada.

Uma linha também pode parecer grave porque um punhado de apps dentro dela entregou algo sério enquanto o resto entregou algo comum. O arquivo de dados abre cada linha por tipo de chave, para dar para ver qual é qual.

Mais da metade dos apps com Supabase que dá para verificar vazam dados de tabela

É o número ao qual voltamos o tempo todo.

Um projeto Supabase é aberto para a internet por definição. O app que roda no navegador conversa direto com o banco de dados, usando uma chave que deve mesmo ser pública, e o que fica entre um estranho e as linhas é o Row Level Security: uma regra em cada tabela. Desligue essa regra, ou escreva uma política que deixa todo mundo entrar, e qualquer tabela do projeto pode ser lida com uma requisição e sem senha.

Menos da metade dos apps que citam um projeto Supabase dá para verificar. Alguns mandam o tráfego do banco pelo próprio backend, onde uma verificação de fora não consegue ir atrás, então sobre esses não dizemos nada. A proporção acima é sobre os apps que responderam.

A divisão é a parte útil. Uma tabela legível chamada settings ou content é um erro. Uma tabela legível chamada users, profiles ou orders é dado pessoal de outra gente na internet aberta, e quem construiu o app quase certamente acha que aquilo é privado.

A verificação nunca lê uma linha. Ela pergunta ao banco quantas linhas ficariam visíveis e lê a contagem de volta num cabeçalho da resposta. Isso basta para distinguir uma tabela com regra de RLS de uma tabela sem regra, e a verificação não vai além disso.

As mesmas nove verificações, ferramenta por ferramenta

Cada app está agrupado pela ferramenta com que foi publicado, e medido contra os outros apps daquela ferramenta.

Quase tudo o que esta tabela compara são padrões de fábrica. Ninguém escolhe Lovable ou Bolt pelos cabeçalhos de segurança. Quem os define para todo app que hospeda é a plataforma, então uma mudança ali mexe numa coluna inteira desta tabela.

Dois limites antes de alguém citar uma linha. Atribuímos os apps pelo domínio de publicação, então um app que mudou para domínio próprio fica inteiramente de fora desta tabela, e esses costumam ser os mais acabados. E uma ferramenta que leva o tráfego do banco pelo próprio backend não pode ser verificada de fora de jeito nenhum. Um espaço em branco ali quer dizer que não conseguimos medir, e não diz nada sobre o quanto esses apps são seguros.

Dois tipos de achado, dois tipos de conserto

Os achados desta página caem em dois grupos, e os dois precisam de mãos diferentes.

O primeiro grupo é uma decisão de produto dentro de uma empresa. Uma única mudança num padrão de fábrica da hospedagem move todos os apps daquela plataforma de uma vez, e é por isso que essas linhas saem tão parelhas e são as mais baratas de consertar.

O segundo grupo está com quem construiu o app. Nenhuma plataforma de hospedagem tem como saber quais das suas tabelas devem ser públicas, nem qual chave pertence a um servidor. Todo achado crítico deste relatório está nesse grupo. Os guias de segurança por ferramenta e o checklist de lançamento começam os dois por ali.

O que os vibe-coders acertam

Contamos também o que passou, sobre os mesmos apps.

O último card é o que os scanners genéricos erram. Uma chave publicável no frontend (uma chave anon do Supabase, uma chave publicável do Stripe) é para estar ali: ela foi feita para ser lida, e a proteção está nas regras atrás dela. Apontar isso como problema manda alguém mudar um ajuste que já estava certo.

Como medimos, e onde estão os limites

Use estes números

Jornalistas, pesquisadores e quem estiver escrevendo sobre o assunto podem reutilizar os dados dando o crédito. O arquivo abaixo traz todos os agregados desta página numa tabela só, e não nomeia nenhum app.