O checklist de segurança do vibe coding, em nove verificações

Você está prestes a mandar o endereço do seu app para alguém, e uma vozinha diz que você devia conferir antes. Então você procura um checklist de segurança do vibe coding e encontra um com vinte e cinco itens, escrito por alguém que supõe que você já sabe o que é uma Content Security Policy.

Aqui está a parte que lista após lista erra: quase nada do que está nelas dá para verificar. "Use senhas fortes" é um conselho. "Limpe o código morto" é arrumação. "Siga o princípio do menor privilégio" é uma frase. Nenhum tem teste, então nenhum pode ser terminado, e uma lista que você não consegue terminar é uma preocupação com números em cima.

Este tem nove itens. Nove é a quantidade de coisas que qualquer pessoa consegue verificar de fora num app no ar, sem a sua senha, sem o seu repositório e sem a sua conta do Supabase. Cada um tem um teste que você mesmo pode fazer e cada teste volta com um sim ou um não.

Pense nisso como a volta que um piloto dá em torno de um avião antes de voar. É curta, tudo que está nela é visível do pátio, e não substitui nada do livro de manutenção. A última seção deste artigo é sobre o livro.

O que deve entrar num checklist de segurança do vibe coding?

Nove perguntas, e são as nove que um estranho poderia fazer ao seu app esta tarde, tendo você conferido ou não.

Nosso scanner de segurança gratuito faz os nove em qualquer URL no ar em cerca de 20 segundos e sem conta, que é o caminho mais rápido para a primeira passada. Ele lê, nunca faz login e nunca escreve nada. Cada item abaixo continua sendo algo que você pode conferir na mão, e os testes estão escritos para que você possa comparar uma linha do nosso relatório com o seu próprio painel.

Os quatro antes de compartilhar o endereço

Chaves secretas, regras do banco de dados, arquivos privados e buckets de storage. Nesses quatro o que fica exposto são seus dados ou seu dinheiro, e os quatro são seus para consertar e não da sua plataforma de hospedagem.

Três deles são as únicas verificações de todo o conjunto capazes de relatar um achado crítico, e a quarta é aquela em que o que fica exposto é o que seus usuários subiram. Entre 12 e 14 de agosto de 2026 rodamos as nove verificações em 30.998 apps de vibe coding no ar, e os números de cada seção abaixo vêm dessa rodada.

1. Tem uma chave secreta no código que seu app envia?

Busque no projeto inteiro por sk_, sb_secret_, service_role e AKIA. Uma ocorrência dentro de qualquer coisa que o navegador baixa é o achado.

Tudo que seu app precisa para rodar num navegador chega nesse navegador, então uma chave que esteja ali chega também. Algumas chaves pertencem a esse lugar: uma chave Supabase anon ou sb_publishable_ é um endereço e não uma permissão, e encontrar uma está certo. Quais chaves são seguras num frontend e quais não são é essa distinção inteira.

Uma chave secreta é do outro tipo. Uma chave Supabase sb_secret_ ou service_role ignora qualquer regra de tabela que você já tenha escrito. Uma chave Stripe sk_live_ move dinheiro. Encontramos uma chave dessa classe em 52 apps de 30.998, o que é raro e é a pior coisa desta lista quando acontece. Se a sua for uma delas, rotacione antes de fazer qualquer outra coisa: apagar a chave do seu código deixa o valor antigo funcionando.

2. Um estranho consegue ler seu banco de dados?

No Supabase, abra o Security Advisor. Toda entrada dizendo que uma tabela é pública mas a segurança por linha não está habilitada é uma tabela respondendo a qualquer um que perguntar, e esse aviso exato tem um artigo só dele.

Row Level Security é a regra que decide, linha por linha, quem pode ver o quê. Sem ela, a chave pública que está no seu app já basta para ler a tabela, e essa chave está no navegador de cada visitante por projeto.

É o achado sério mais comum de todo o conjunto: 2.096 dos 3.680 apps cujo projeto Supabase nos respondeu, ou 57 %, tinham pelo menos uma tabela entregando linhas para uma requisição sem ninguém logado. Ligar em toda tabela é o conserto. O advisor lê suas configurações e não as respostas do seu banco, então termine conferindo de fora: uma tabela pode estar com a configuração ligada e uma política que deixa todo mundo passar mesmo assim.

3. Qualquer um consegue baixar seus arquivos privados?

Abra seuapp.com/.env e seuapp.com/.git/config numa janela anônima. Os dois deveriam se recusar a abrir.

Um arquivo .env é cada chave que você acreditava estar a salvo no servidor, numa lista simples, num endereço adivinhável. Uma pasta .git é o histórico do seu projeto. Nenhum dos dois deveria ser servido, e de vez em quando são, normalmente porque um build copiou uma pasta que não devia.

É a coisa mais rara que encontramos: 8 apps de 30.749. Também são cinco segundos de trabalho para descartar, e é de onde vêm os vazamentos mais danosos quando acontece.

4. Seus buckets de storage listam o que têm dentro?

No Supabase, abra Storage. Leia a coluna Public em cada bucket e depois abra as políticas de qualquer bucket que guarde algo que não é para todo mundo.

Aqui acontecem duas coisas diferentes e é fácil misturar. Um bucket público serve qualquer arquivo cujo nome alguém já conheça. Um bucket listável entrega os nomes, o que transforma "alguém teria que adivinhar" num diretório dos uploads dos seus usuários. Nossa verificação testa o segundo, porque é o que muda o que um estranho de fato consegue fazer.

792 apps de 27.269 tinham um bucket que se listou para nós sem login. O que um estranho tira dessa lista é a versão longa, e o conserto costuma ser uma chavinha mais uma política.

Os cinco que podem esperar até você ter usuários

Cabeçalhos, source maps, seus próprios endereços de API, o certificado e o domínio. Três deles normalmente são definidos por quem hospeda seu app, e dois são datas num calendário.

Nenhum deles entrega sozinho uma linha do seu banco de dados, e é por isso que ficam no segundo grupo. Um dos cinco vale adiantar se seu app tem um backend próprio, e ele está marcado abaixo.

5. Os cabeçalhos de segurança do navegador estão ligados?

Este é o único item da lista sem uma versão que dá para fazer pela barra de endereços. Um scan lê os cabeçalhos, ou você abre as ferramentas de desenvolvedor do navegador, vai na aba Rede, clica na primeira requisição e lê os cabeçalhos da resposta.

São instruções pequenas para o navegador: carregue esta página só por HTTPS, recuse ser emoldurada por outro site, não adivinhe tipos de arquivo. A ausência deles não expõe nada por si só. Ela tira proteções que deixam outros ataques mais difíceis.

Quase ninguém passa neste item e quase ninguém pode. A 30.756 apps de 30.981 faltava pelo menos um, e num subdomínio de builder a configuração é da plataforma. Se dá para fazer algo com os seus depende inteiramente de onde seu app está hospedado.

6. Seu código-fonte original está publicado?

Abra seu app no ar, abra as ferramentas de desenvolvedor do navegador e olhe o painel Sources. Se seus próprios arquivos aparecem ali com o código que você escreveu e os comentários que você deixou, os source maps saíram com o build.

Um source map é uma tabela de tradução que devolve o arquivo comprimido que seu app envia para código legível. Desenvolvedores usam para depurar um site no ar. Publicado na internet, significa que qualquer um pode ler seu app do jeito que você escreveu.

3.885 apps de 30.987 publicaram os seus. Não é um vazamento por si só, e vira um quando o código contém algo que você supunha que ninguém leria. O que um source map publicado expõe cobre a diferença e a configuração de build que desliga isso.

7. Seus próprios endereços de API respondem a um estranho?

Copie um dos endereços de API do seu app da aba Rede e depois abra numa janela anônima onde você não está logado. Veja o que volta.

Este é o item para adiantar se seu app tem um backend próprio, porque tudo que um endereço entrega para uma requisição sem login é público, seja qual for a cara da página na frente dele. 3.852 apps de 30.926 tinham pelo menos um.

A configuração aparentada é o CORS, que decide quais outros sites podem chamar seu app do navegador de um visitante. Um curinga ali muitas vezes está tudo bem e de vez em quando não, e qual dos dois você tem vale ler antes de mudar qualquer coisa.

8. Seu certificado está prestes a vencer?

Clique no cadeado da barra de endereços, abra o certificado e leia a data de "Válido até".

Quase toda hospedagem renova isso sozinha e quase todas conseguem. 32 apps de 30.851 tinham um certificado vencido, vencendo ou não confiável. Quando falha, os visitantes recebem um aviso do navegador em tela cheia dizendo que seu site não é seguro, e a maioria vai embora.

9. Seu domínio está renovado?

Entre no seu registrador, leia a data de vencimento e confira se a renovação automática está ligada e se o cartão por trás dela não venceu.

É o item menos técnico da lista e o único que consegue tirar seu app da internet por completo. 55 apps de 30.980 tinham um domínio vencido ou vencendo. Um nome que caducou também pode ser registrado por outra pessoa, junto com cada link que alguém já apontou para ele.

O que outros checklists carregam que não é verificação de segurança

Backups, monitoramento de erros, código morto e conselho sobre senhas. O primeiro é o que tem mais chance de te custar alguma coisa, e não é verificação de segurança, porque nada fora do seu app consegue dizer se você tem um.

Essa é a razão honesta de ele faltar entre os nove. Um scanner lê seu site no ar; um backup é uma cópia do seu banco de dados guardada em outro lugar, e nenhum olhar de fora para o seu app consegue dizer se ela existe, se está em dia ou se restauraria. Ainda assim ele entra na sua lista. Ele entra no tipo de lista que se mantém, não no tipo que se percorre.

Os backups do próprio Supabase dependem do seu plano e ficam dentro da sua conta do Supabase, o que está ótimo até o problema ser a conta. Os três caminhos para uma cópia que é sua expõe o que cada um cobre.

Se você preferir que isso aconteça sem você, é o que o Reeve Care faz. Ele tira uma cópia do seu banco Supabase numa frequência definida pelo plano que você tem, toda noite no nível de entrada e até quatro vezes por dia no mais alto, lê cada cópia de volta antes de ela contar como backup, e guarda onde o Supabase não alcança. Até onde você consegue voltar é definido do mesmo jeito. Restaurar é um botão, e ele tira uma foto do estado atual antes de começar, então apertar no desespero não destrói o que você estava tentando salvar. Os arquivos enviados vêm junto, assim que você conecta uma credencial de Storage, pedida à parte porque é a única chave que temos capaz de escrever: o Supabase não emite chave somente leitura para arquivos. O Care começa em $49 por mês para um app, e esse é um preço de tabela, então a página de preços às vezes está abaixo do valor aqui e nunca acima. Como uma cópia é tirada, conferida e devolvida está desenhado passo a passo na página de backups do Supabase.

O resto do que essas listas carregam é trabalho de verdade e não este trabalho. Monitoramento de erros te diz quando seu app quebra, e isso é operação. "Remova dependências não usadas" é arrumação. "Use senhas fortes" vale para tudo em que você já fez login.

De quanto em quanto tempo devo refazer isso?

Depois de todo deploy que mexeu nas regras do banco, nas suas chaves ou nas configurações de build. Se isso soa como a maioria dos deploys, costuma ser mesmo, e aí está o problema de verdade de um checklist que se percorre uma vez.

A volta no avião acontece antes de cada voo exatamente por isso. Row Level Security é desligada à meia-noite para uma página carregar e ninguém liga de volta. Uma chave é colada no frontend para entregar um recurso antes de uma demo. Um bucket é aberto para um upload e fica aberto. Cada uma dessas coisas é uma terça-feira normal, e cada uma basta para virar um resultado limpo num resultado sério.

O Reeve Monitor existe para esse buraco. Ele refaz as nove verificações a cada hora em até três apps, olha a cada 60 segundos se o app está de pé, te avisa no dia em que um resultado muda em vez de esperar você olhar, e manda um relatório mensal em linguagem simples. Custa $12 por mês de tabela, com sete dias grátis antes de cobrar, e a página de preços às vezes está abaixo do valor aqui e nunca acima. O Monitor vigia e nada mais. Backups são o plano Care acima dele, e o Care guarda uma cópia de um banco Supabase e de nada mais.

O que nada disso prova

Que seu app é seguro. Nove verificações voltando limpas querem dizer que nove perguntas feitas de fora voltaram limpas no dia em que você as fez.

Quatro coisas continuam invisíveis para cada item desta lista, porque nenhuma delas sai do seu servidor. Seu código de servidor, incluindo as funções de banco e as edge functions que ninguém de fora consegue ler. As variáveis de ambiente que você manteve fora do navegador, que é exatamente o lugar delas e também o motivo de um scan não conseguir confirmar que estão bem guardadas. Seu histórico de versões, onde uma chave que você commitou em março e removeu em abril continua sentada. E a lógica do seu próprio app, como se um usuário logado consegue abrir o pedido de outro mudando um número no endereço.

O que um scan por URL enxerga e o que não enxerga percorre essa fronteira direito, incluindo as três ferramentas que leem coisas diferentes e onde cada uma é cega.

O que fazer agora

Se seu app guarda os dados no Supabase, a versão escrita em torno desse stack é o guia de apps Supabase. E se você prefere algo para marcar em vez de algo para ler, o checklist de segurança de 10 minutos é a versão interativa.