FixVibe

// docs / security guides / cursor checklist

Checklist sicurezza Cursor: 28 voci prima del deploy

Costruire con Cursor? Il completamento automatico, la modalità Composer e le funzionalità Agente di Cursor sono eccezionalmente potenti e creano punti ciechi di sicurezza prevedibili. Questo elenco di controllo si rivolge a modelli specifici di Cursor: integrazione della chiave del ruolo di servizio, interi file generati dal compositore senza revisione, comandi del terminale in modalità agente e il file <code>.cursorrules</code> come primo guardrail di sicurezza. 28 elementi tra segreti, database, autenticazione, intestazioni, distribuzione e trucchi specifici di Cursor.

PRE = pre-distribuzione (controlla la tua origine). DEPLOY = al momento della distribuzione. POST = verifica post-distribuzione. Gli elementi fanno riferimento a FixVibe, controlla gli ID nel modulo category.check-id, ove pertinente.

Segreti e chiavi API (5 articoli)

Il completamento automatico di Cursor è addestrato su codice open source in cui i segreti sono comuni. Il modello li suggerisce liberamente, soprattutto dopo un tentativo di autenticazione fallito.

  1. PRE — Write security rules into .cursorrules. Aggiungi una riga: "Non incorporare mai SUPABASE_SERVICE_ROLE_KEY, sk_live_* o qualsiasi variabile env che inizia con l'acronimo del provider nel codice lato client. Utilizza sempre importazioni solo server." Cursor legge .cursorrules e lo inserisce in ogni suggerimento.
  2. PRE — Audit Composer-generated files. Quando il compositore di Cursor crea un intero file (in particolare i gestori di autenticazione), rivedilo riga per riga. Il compositore a volte incorpora variabili env che dovrebbero rimanere solo sul server. Cerca NEXT_PUBLIC_ o riferimenti diretti alle chiavi di servizio nelle importazioni di componenti.
  3. PRE — Reject auto-imports of service clients into client components. Se Composer importa import { supabase } from '@/lib/supabase/service' in un file React, eliminalo immediatamente e instradalo invece attraverso un endpoint API. Le importazioni solo server sono contrassegnate esplicitamente: non saltarle.
  4. PRE — Scan Agent-mode commits. La modalità agente esegue comandi del terminale e può eseguire il commit direttamente. Controlla git log --oneline -20 e git diff HEAD~5 per garantire che non siano state eseguite stringhe dall'aspetto segreto durante l'esecuzione dell'agente.
  5. POST — Run secrets.browser-storage. Scansione passiva sul URL distribuito. Se una chiave di servizio appare nel bundle JS, ruotala immediatamente: probabilmente il completamento automatico di Cursor l'ha incorporata.

Controllo dell'accesso al database (4 articoli)

Composer spesso genera un codice di autenticazione funzionante ma salta RLS: il momento "funziona" impedisce alle persone di vedere la mancata applicazione delle policy.

  1. PRE — Force Cursor to generate migrations with RLS. In .cursorrules: "Ogni migrazione CREATE TABLE public.* deve includere ALTER TABLE ... ENABLE ROW LEVEL SECURITY e FORCE ROW LEVEL SECURITY." Quindi chiedi a Composer di generare la migrazione.
  2. PRE — Review Composer-generated policies. Il compositore a volte scrive le policy senza controllare auth.uid(). Politiche come allow select on public.items senza una clausola using sono pericolosamente ampie. Richiede la corrispondenza user_id.
  3. DEPLOY — Confirm FORCE ROW LEVEL SECURITY is live. Apri Supabase Studio, controlla l'interruttore RLS di ciascuna tabella. Se la migrazione di Composer aveva ENABLE ma ha dimenticato FORCE, i proprietari della tabella (le tue migrazioni) bypassano RLS. Questo è un vero divario.
  4. POST — Run the baas.supabase-rls active check. Tenta una scrittura con la chiave anon. Se ha esito positivo, RLS in realtà non viene applicato, probabilmente manca la parola chiave FORCE.

Autenticazione e sessioni (4 articoli)

Cursor genera rapidamente flussi di autenticazione ma spesso manca la sottile convalida lato server che mantiene i token al sicuro.

  1. PRE — Ensure all auth routes use getUser(). Cerca getSession() nei tuoi percorsi API e sostituisci con await supabase.auth.getUser(). getSession() legge un cookie non verificato; getUser() convalida con il backend Supabase.
  2. PRE — Check Composer auth handlers for token expiry. I token Magic-link richiedono l'applicazione del server expires_at. Il valore predefinito Supabase è 1 ora: non chiedere a Cursor di sovrascriverlo senza un motivo reale.
  3. PRE — Audit the sign-in redirect guard. Il reindirizzamento del parametro di query next dopo l'accesso deve essere convalidato: deve iniziare con /, mai //. Il compositore a volte lo salta. Aggiungilo manualmente se mancante.
  4. POST — Test logout server-side state destruction. Accedi, esci, controlla i cookie (DevTools → Applicazione → Cookie). Il cookie di sessione deve essere cancellato immediatamente. Se persiste, il gestore del logout non sta distruggendo lo stato.

HTTP intestazioni di sicurezza e CSP (3 elementi)

Cursor raramente genera middleware per impostazione predefinita. Se non lo chiedi esplicitamente, CSP e HSTS di solito non ci sono.

  1. PRE — Demand CSP in .cursorrules. Aggiungere: "Genera un src/middleware.ts con Content-Security-Policy. Utilizza nonce per script-src, no unsafe-inline." Quindi chiedi a Cursor di generarlo. Senza questo suggerimento, il middleware viene saltato.
  2. PRE — Verify src/middleware.ts exists. Con il layout della directory src/, Next.js rileva solo src/middleware.ts. Un middleware.ts a livello root viene silenziosamente ignorato. Se CSP non viene visualizzato, controlla che il file sia nel posto giusto.
  3. POST — Run headers.security-headers. Rapporti di scansione passiva mancanti CSP, HSTS, X-Frame-Options, X-Content-Type-Options. Apri il report e segui le indicazioni per la correzione per la tua piattaforma di distribuzione.

Igiene della distribuzione (5 articoli)

Le app Cursor spesso arrivano a Vercel, che ha buone impostazioni predefinite ma necessita di un rafforzamento esplicito per il limite build/deploy.

  1. DEPLOY — Check Vercel env-var scoping. Impostazioni → Variabili d'ambiente → ciascun segreto deve avere come ambito solo Production. Non condividere mai sk_live_* con Anteprima o Sviluppo.
  2. DEPLOY — Disable build-log secret echo. Se il tuo flusso di lavoro vercel.json o GitHub Actions ha echo $SECRET, rimuovilo. I log di build vengono archiviati pubblicamente; i segreti nei log sono compromessi.
  3. DEPLOY — Use Vercel's managed secrets, not inline workflow vars. Impostazioni di Vercel → Variabili d'ambiente sono crittografate quando sono inattive. GitHub I segreti delle azioni sono meglio di niente ma sono progettati per CI, non per l'integrazione della piattaforma di distribuzione.
  4. POST — Verify CSP nonce on the deployed preview. Apri un collegamento Vercel Anteprima nel browser, apri DevTools → Rete → la risposta root HTML. L'intestazione CSP deve essere presente e includere 'strict-dynamic' con un nonce univoco per richiesta.
  5. POST — Rotate any key that ever shipped, even to Preview. Se una chiave raggiunge il bundle di produzione anche per 10 minuti, è compromessa. Gira subito.

Cursor trucchi specifici (4 articoli)

Modelli esclusivi del flusso di lavoro di Cursor che creano rischi per la sicurezza:

  1. Agent mode auto-fixes propagate old patterns. Se chiedi all'agente di "correggere gli errori di autenticazione", potrebbe rigenerare lo stesso file di autenticazione più volte, ogni volta incorporando la stessa chiave di servizio se si trova nel contesto codebase. Pulisci prima l'originale, poi chiedi all'agente di ripararlo.
  2. Cursor Index leaks intent. Cursor L'indicizzazione di @codebase è potente ma se la tua directory .cursor viene esposta (S3 configurato in modo errato, cronologia git), l'indice rivela la tua architettura e i tuoi modelli segreti. Mantieni .cursor locale.
  3. Composer mode loses context between files. Ogni file generato da Composer è aggiornato. Se gli chiedi di generare un file client, quindi un percorso API, potrebbero utilizzare diverse configurazioni client Supabase. Esaminali entrambi e assicurati che corrispondano alla tua architettura.
  4. Autocomplete bias toward "working" over "secure". Cursor suggerisce il codice più veloce che supera il contesto attuale. Se il tuo test ha NEXT_PUBLIC_SERVICE_KEY, il completamento automatico lo ricorda e lo ripropone. Pulisci i dispositivi di prova prima di condividere il codice con il modello.

Prossimi passi

Una volta bloccati i modelli specifici di Cursor, effettuare un controllo incrociato con general vibe coding security checklist (44 elementi) e poi con step-by-step hardening. Vedi anche Claude Code checklist se stai mixando strumenti.

// scansiona la tua app

Smetti di leggere. Inizia a trovare le falle nella tua.

Incolla una URL — FixVibe esegue ogni controllo passivo di questa guida più 200 altri in meno di un minuto. Gratis, senza installazione, senza carta.

  • Free tier — 3 scansioni / mese, senza carta.
  • Scansioni passive contro qualsiasi URL — nessuna verifica di dominio.
  • Ottimizzato per Cursor, Claude Code, Lovable, Bolt, v0, Replit.
  • Coding-agent prompts for code/config findings, plus operator steps for DNS/provider fixes.
Checklist sicurezza Cursor: 28 voci prima del deploy — Docs · FixVibe