// docs / security guides / cursor checklist

Checklist de segurança Cursor: 28 itens antes do deploy

Construindo com Cursor? O preenchimento automático, o modo Composer e os recursos de agente do Cursor são excepcionalmente poderosos e criam pontos cegos de segurança previsíveis. Esta lista de verificação tem como alvo padrões específicos de Cursor: inclusão de chave de função de serviço, arquivos inteiros gerados pelo Composer sem revisão, comandos de terminal no modo Agente e o arquivo <code>.cursorrules</code> como sua primeira proteção de segurança. 28 itens entre segredos, banco de dados, autenticação, cabeçalhos, implantação e pegadinhas específicas de Cursor.

PRE = pré-implantar (audite sua fonte). DEPLOY = no momento da implantação. POST = verificação pós-implantação. Referência de itens FixVibe verifique IDs no formulário category.check-id quando relevante.

Segredos e chaves API (5 itens)

O preenchimento automático de Cursor é treinado em código-fonte aberto, onde segredos são comuns. O modelo os sugere livremente, especialmente após uma tentativa de autenticação fracassada.

PRE — Write security rules into .cursorrules. Adicione uma linha: "Nunca inline SUPABASE_SERVICE_ROLE_KEY, sk_live_* ou qualquer env var começando com um acrônimo de provedor no código do lado do cliente. Sempre use importações somente de servidor." Cursor lê .cursorrules e considera isso em cada sugestão.
PRE — Audit Composer-generated files. Quando o Composer de Cursor cria um arquivo inteiro (especialmente manipuladores de autenticação), revise-o linha por linha. O Composer às vezes incorpora env vars que devem permanecer apenas no servidor. Procure NEXT_PUBLIC_ ou referências diretas a chaves de serviço nas importações de componentes.
PRE — Reject auto-imports of service clients into client components. Se o Composer importar import { supabase } from '@/lib/supabase/service' para um arquivo React, exclua-o imediatamente e roteie através de um endpoint API. As importações somente de servidor são explicitamente marcadas — não as ignore.
PRE — Scan Agent-mode commits. O modo Agente executa comandos de terminal e pode confirmar diretamente. Audite git log --oneline -20 e git diff HEAD~5 para garantir que nenhuma string de aparência secreta tenha sido confirmada durante uma execução do Agente.
POST — Run secrets.browser-storage. Verificação passiva no URL implantado. Se uma chave de serviço aparecer no pacote JS, gire-a imediatamente - o preenchimento automático de Cursor provavelmente a incorporou.

Controle de acesso ao banco de dados (4 itens)

O Composer geralmente gera código de autenticação funcional, mas ignora RLS — o momento "funciona" cega as pessoas para a falta de aplicação da política.

PRE — Force Cursor to generate migrations with RLS. Em .cursorrules: "Cada CREATE TABLE public.* migração deve incluir ALTER TABLE ... ENABLE ROW LEVEL SECURITY e FORCE ROW LEVEL SECURITY." Em seguida, peça ao Composer para gerar a migração.
PRE — Review Composer-generated policies. O Composer às vezes escreve políticas sem verificar auth.uid(). Políticas como allow select on public.items sem uma cláusula using são perigosamente amplas. Exigir correspondência user_id.
DEPLOY — Confirm FORCE ROW LEVEL SECURITY is live. Abra Supabase Studio, verifique a alternância RLS de cada tabela. Se a migração do Composer teve ENABLE mas esqueceu FORCE, os proprietários da tabela (suas migrações) ignoram RLS. Esta é uma verdadeira lacuna.
POST — Run the baas.supabase-rls active check. Tenta escrever com a tecla anon. Se tiver sucesso, RLS não está realmente aplicando - provavelmente faltando a palavra-chave FORCE.

Autenticação e sessões (4 itens)

Cursor gera fluxos de autenticação rapidamente, mas muitas vezes perde a validação sutil do lado do servidor que mantém os tokens seguros.

PRE — Ensure all auth routes use getUser(). Pesquise getSession() em suas rotas API e substitua por await supabase.auth.getUser(). getSession() lê um cookie não verificado; getUser() valida com Supabase back-end.
PRE — Check Composer auth handlers for token expiry. Os tokens Magic-link precisam ser aplicados pelo servidor expires_at. O padrão Supabase é 1 hora — não peça a Cursor para substituí-lo sem um motivo real.
PRE — Audit the sign-in redirect guard. O redirecionamento do parâmetro de consulta next após o login deve ser validado: deve começar com /, nunca //. O compositor às vezes pula isso. Adicione-o manualmente se estiver faltando.
POST — Test logout server-side state destruction. Faça login, saia, inspecione cookies (DevTools → Aplicativo → Cookies). O cookie da sessão deve ser apagado imediatamente. Se persistir, o manipulador de logout não está destruindo o estado.

HTTP cabeçalhos de segurança e CSP (3 itens)

Cursor raramente gera middleware por padrão. Se você não perguntar explicitamente, CSP e HSTS geralmente não estão lá.

PRE — Demand CSP in .cursorrules. Adicione: "Gere um src/middleware.ts com Content-Security-Policy. Use nonce para script-src, não inseguro-inline." Então peça a Cursor para gerá-lo. Sem essa dica, o middleware é ignorado.
PRE — Verify src/middleware.ts exists. Com o layout de diretório src/, Next.js seleciona apenas src/middleware.ts. Um middleware.ts de nível raiz é ignorado silenciosamente. Se CSP não estiver chegando, verifique se o arquivo está no lugar certo.
POST — Run headers.security-headers. Relatórios de verificação passiva faltando CSP, HSTS, X-Frame-Options, X-Content-Type-Options. Abra o relatório e siga as orientações de correção para sua plataforma de implantação.

Higiene de implantação (5 itens)

Os aplicativos Cursor geralmente chegam a Vercel, que tem bons padrões, mas precisa de proteção explícita para o limite build/deploy.

DEPLOY — Check Vercel env-var scoping. Configurações → Variáveis de ambiente → cada segredo deve ter como escopo apenas Production. Nunca compartilhe sk_live_* com visualização ou desenvolvimento.
DEPLOY — Disable build-log secret echo. Se o seu fluxo de trabalho vercel.json ou GitHub Actions tiver echo $SECRET, remova-o. Os logs de compilação são arquivados publicamente; segredos nos logs são comprometidos.
DEPLOY — Use Vercel's managed secrets, not inline workflow vars. Vercel Configurações → Variáveis de ambiente são criptografadas em repouso. GitHub Os segredos das ações são melhores do que nada, mas são projetados para CI, não para integração de plataforma de implantação.
POST — Verify CSP nonce on the deployed preview. Abra um link de visualização Vercel no navegador, abra DevTools → Rede → a resposta raiz HTML. O cabeçalho CSP deve estar presente e incluir 'strict-dynamic' com um nonce exclusivo por solicitação.
POST — Rotate any key that ever shipped, even to Preview. Se uma chave chegar ao pacote de produção por até 10 minutos, ela estará comprometida. Gire imediatamente.

pegadinhas específicas de Cursor (4 itens)

Padrões exclusivos do fluxo de trabalho de Cursor que criam riscos de segurança:

Agent mode auto-fixes propagate old patterns. Se você pedir ao Agente para "corrigir erros de autenticação", ele poderá regenerar o mesmo arquivo de autenticação várias vezes, sempre incorporando a mesma chave de serviço se estiver no contexto da base de código. Limpe o original primeiro e depois peça ao Agente para consertar.
A indexação Cursor Index leaks intent. Cursor @codebase é poderosa, mas se o seu diretório .cursor for exposto (S3 mal configurado, histórico do git), o índice revela sua arquitetura e padrões secretos. Mantenha .cursor local.
Composer mode loses context between files. Cada arquivo gerado pelo Composer é novo. Se você solicitar que ele gere um arquivo de cliente e, em seguida, uma rota API, eles poderão usar configurações de cliente Supabase diferentes. Revise ambos e certifique-se de que correspondam à sua arquitetura.
Autocomplete bias toward "working" over "secure". Cursor sugere o código mais rápido que passa no seu contexto atual. Se o seu teste tiver NEXT_PUBLIC_SERVICE_KEY, o preenchimento automático lembra e sugere novamente. Limpe os acessórios de teste antes de compartilhar o código com o modelo.

Próximas etapas

Depois de bloquear os padrões específicos de Cursor, verifique com general vibe coding security checklist (44 itens) e depois com step-by-step hardening. Veja também Claude Code checklist se você estiver mixando ferramentas.