Seu app do Cursor é seguro?

O Cursor te dá controle de verdade (o seu repositório, os seus arquivos, o seu deploy), e isso muda onde o risco fica. Você não está se perguntando o que um builder fez em seu nome. Você está revisando muito código que funciona, rapidamente, e decidindo o que ler com atenção.

Aqui está o que guia após guia erra: perguntar se a IA escreve código inseguro é a pergunta errada. Código gerado é escrito para atender o que você pediu. "Carregue os pedidos do usuário" é atendido por um código que carrega pedidos. Nada nessa frase diz de quem, então nada na resposta decide, e o lugar a que essa decisão pertence não é o arquivo que você está revisando.

Funcionar e estar protegido são dois testes diferentes

Só um deles roda sozinho.

Pense numa loja. O seu app é a vitrine: cada página que você constrói é entregue inteira a cada visitante, porque um navegador não desenha o que não lhe enviaram. O seu banco de dados é o estoque, um prédio separado na internet, com fechadura e endereço próprios.

Quando você roda o seu app e ele funciona, você testou a vitrine: as coisas certas aparecem nas telas certas, para você. Você não testou a fechadura. O estoque é alcançável direto, sem passar pela sua loja, e o fato de o seu app carregar direitinho não diz nada sobre o que ele devolve para quem pula a porta da frente.

Esse é o teste que nunca roda sozinho, em nenhum projeto, gerado ou escrito à mão. Fica mais fácil pular quando o código chega mais rápido do que você lê.

Onde as chaves dão errado num projeto do Cursor

Na mudança de servidor para navegador, quase sempre.

Existem dois tipos de credencial e eles parecem quase iguais. Uma chave publicável nomeia o seu projeto e nada mais (sb_publishable_… nos projetos novos do Supabase, anon nos antigos), e foi feita para viver num navegador. Uma chave secreta, sb_secret_… ou a antiga service_role, ignora todas as regras que você escreveu e consegue ler e escrever em cada linha que você tem.

A sequência que publica uma delas é banal. Código que usava uma chave secreta no servidor é refatorado para um componente que roda no navegador. O valor volta como undefined, então a variável é renomeada com o prefixo que a ferramenta de build quer (NEXT_PUBLIC_ no Next.js, VITE_ no Vite), e o app começa a funcionar. A própria documentação do Vite é direta sobre o que esse prefixo faz: esses valores vão empacotados no seu código-fonte na hora do build.

O .gitignore não ajuda aqui. Ele governa o que entra no repositório, e a saída do build é gerada depois. Se você prefere ter certeza de qual chave é qual, existe uma conferência de um minuto.

A conferência que pertence ao banco de dados

Row Level Security, se os seus dados estão no Supabase, uma chave por tabela que decide linha a linha quem pode ler o quê.

Essa é a resposta ao problema do "carregue os pedidos". Em vez de confiar que toda consulta do código vá filtrar direito, o banco se recusa a devolver linhas a que o visitante não tem direito, não importa o que a consulta dizia nem quem a escreveu. Uma regra, aplicada no único lugar por onde todo pedido tem que passar.

Dois detalhes decidem se você tem isso. O Supabase liga o Row Level Security por padrão nas tabelas criadas no Table Editor do painel, e não nas criadas rodando SQL, que é como um arquivo de migração as cria. E a configuração só liga a conferência; quem passa é a política por trás que decide, e uma política pode permitir todo mundo mesmo assim.

Como conferir o seu próprio projeto do Cursor em uns dez minutos

Procure na saída do seu build, não no código-fonte. Compile o app e depois procure nos arquivos gerados por service_role, sb_secret_ e sk_live_. Tudo que aparecer está publicado. Isso é mais rápido e mais honesto do que ler o fonte, porque é o que os visitantes realmente recebem.

Leia o seu arquivo de ambiente procurando prefixos. Toda variável NEXT_PUBLIC_ ou VITE_ é pública por projeto. Para cada uma, pergunte se você a imprimiria na sua página inicial.

Abra Authentication → Policies no Supabase. Qualquer tabela mostrando Row Level Security como desligado pode ser lida por quem tiver o endereço do seu projeto, que está dentro do seu app.

E então olhe de fora. O nosso scan gratuito faz esse último passo por você: ele lê o seu site no ar como um visitante e te dá uma nota em uns 20 segundos, sem precisar de conta: escaneie seu app.

Compile o seu projeto e procure service_role e sk_live_ na saída antes de qualquer outra coisa; leva um minuto e a resposta não deixa dúvida. Depois disso, o checklist de segurança de 10 minutos é o caminho mais curto pelo resto.