La tua app Cursor è sicura?

Cursor ti dà controllo vero (il tuo repository, i tuoi file, il tuo deploy), e questo sposta il punto in cui sta il rischio. Non ti stai chiedendo che cosa abbia fatto un builder al posto tuo. Stai rileggendo molto codice che funziona, in fretta, e decidendo che cosa leggere con attenzione.

Ecco il punto che guida dopo guida racconta male: chiedersi se l'IA scriva codice non sicuro è la domanda sbagliata. Il codice generato è scritto per soddisfare quello che hai chiesto. «Carica gli ordini dell'utente» è soddisfatto da codice che carica ordini. In quella frase non c'è scritto di chi, quindi nella risposta non c'è nulla che lo decida, e il posto a cui quella decisione appartiene non è il file che stai rileggendo.

Funzionare ed essere protetti sono due prove diverse

Solo una delle due parte da sola.

Pensala come un negozio. La tua app è la vetrina: ogni pagina che costruisci viene consegnata per intero a ogni visitatore, perché un browser non può disegnare ciò che non gli è stato inviato. Il tuo database è il magazzino, un edificio separato su internet con la sua serratura e il suo indirizzo.

Quando avvii la tua app e funziona, hai messo alla prova la vetrina: per te compaiono le cose giuste sulle schermate giuste. Non hai messo alla prova la serratura. Il magazzino è raggiungibile direttamente, senza passare dal tuo negozio, e il fatto che la tua app si carichi correttamente non dice nulla su che cosa restituisca a chi salta la porta d'ingresso.

È la prova che non parte mai da sola, in nessun progetto, generato o scritto a mano. Diventa più facile da saltare quando il codice arriva più in fretta di quanto tu riesca a leggerlo.

Dove vanno storte le chiavi in un progetto Cursor

Nel passaggio dal server al browser, quasi sempre.

Esistono due tipi di credenziale e si somigliano quasi in tutto. Una chiave pubblicabile nomina il tuo progetto e nient'altro (sb_publishable_… nei progetti Supabase nuovi, anon in quelli più vecchi), ed è progettata per vivere in un browser. Una chiave segreta, sb_secret_… o la più vecchia service_role, ignora ogni regola tu abbia scritto e può leggere e scrivere ogni riga che possiedi.

La sequenza che ne pubblica una è ordinaria. Codice che usava una chiave segreta sul server viene rifattorizzato in un componente che gira nel browser. Il valore torna undefined, quindi la variabile viene rinominata con il prefisso che lo strumento di build vuole (NEXT_PUBLIC_ in Next.js, VITE_ in Vite), e l'app comincia a funzionare. La documentazione di Vite è esplicita su che cosa fa quel prefisso: quei valori finiscono nel tuo codice sorgente al momento della build.

.gitignore qui non aiuta. Governa ciò che finisce nel repository, e l'output della build viene generato dopo. Se preferisci essere sicuro di quale delle tue chiavi sia quale, esiste un controllo da un minuto.

Il controllo che appartiene al database

La Row Level Security, se i tuoi dati sono in Supabase, è un interruttore per tabella che decide riga per riga chi può leggere cosa.

Questa è la risposta al problema del «carica gli ordini». Invece di fidarsi che ogni query nel codice filtri correttamente, il database rifiuta di restituire righe a cui il visitatore non ha diritto, qualunque cosa dicesse la query e chiunque l'abbia scritta. Una regola, applicata nell'unico punto da cui ogni richiesta deve passare.

Due dettagli decidono se ce l'hai. Supabase attiva la Row Level Security per impostazione predefinita sulle tabelle create nel Table Editor del pannello, e non su quelle create eseguendo SQL, che è il modo in cui le crea un file di migrazione. E l'impostazione accende soltanto il controllo; chi passa lo decide la policy che sta dietro, e una policy può permettere comunque a tutti.

Come controllare il tuo progetto Cursor in una decina di minuti

Cerca nell'output della build, non nei sorgenti. Compila l'app, poi cerca nei file generati service_role, sb_secret_ e sk_live_. Tutto ciò che salta fuori è pubblicato. È più rapido e più onesto che leggere i sorgenti, perché è ciò che i visitatori ricevono davvero.

Leggi il tuo file d'ambiente cercando i prefissi. Ogni variabile NEXT_PUBLIC_ o VITE_ è pubblica per costruzione. Per ognuna, chiediti se la stamperesti in homepage.

Apri Authentication → Policies in Supabase. Qualsiasi tabella che mostri la Row Level Security come disattivata è leggibile da chiunque possieda l'indirizzo del tuo progetto, che sta dentro la tua app.

E poi guarda da fuori. La nostra scansione gratuita fa quest'ultimo passo per te: legge il tuo sito dal vivo come un visitatore e ti dà un voto in una ventina di secondi, senza account: scansiona la tua app.

Compila il tuo progetto e cerca service_role e sk_live_ nell'output prima di qualsiasi altra cosa; richiede un minuto e la risposta non è ambigua. Dopo, la checklist di sicurezza in 10 minuti è la strada più breve attraverso il resto.