Sicurezza per il codice che scrivi con Cursor

"Sicurezza in Cursor" significa due cose diverse, e conviene tenerle separate. La prima è proteggere la tua configurazione di Cursor: cosa esce dalla tua macchina, cosa può eseguire l'agente senza chiedertelo e di quali server e file di regole ti fidi. La seconda è proteggere il codice che Cursor scrive per te, che è quello che finisce online ed esposto a internet. Questa guida copre entrambe, con un blocco di regole pronto da incollare nel tuo progetto e un prompt di revisione da usare prima di ogni deploy.

Parte 1: proteggere la tua configurazione di Cursor

Cosa esce dalla tua macchina

Cursor invia ai suoi server, e a quelli del fornitore del modello, il contesto di cui ha bisogno per rispondere: il file aperto, ciò che indicizza del progetto e quello che incolli nella chat. Attiva la modalità privacy nelle impostazioni se non vuoi che quel codice venga memorizzato né usato per l'addestramento; nei team, imponila dal piano. E ricorda che tutto ciò che incolli nella chat viaggia: non incollare dump del database né file di credenziali "perché capisca".

Escludi i segreti dall'indicizzazione

Cursor indicizza il progetto per dare contesto al modello. Un .env, un service-account.json o una cartella di certificati non dovrebbero far parte di quell'indice. Crea un file .cursorignore nella root con i pattern da escludere; segue la sintassi di .gitignore:

.env
.env.*
*.pem
*.key
**/service-account*.json
secrets/

Se qualcosa di sensibile era già indicizzato, rimuovilo dall'indice dalle impostazioni e, se era una chiave vera, ruotala.

Esecuzione automatica dei comandi

L'agente di Cursor può eseguire comandi da terminale per conto suo se glielo permetti. È comodo ed è pericoloso: un prompt frainteso, o un testo malevolo che l'agente legge da un file o da una pagina web, può finire in un rm -rf, un git push --force o un curl | sh. Mantieni la conferma manuale per i comandi che cancellano, pubblicano o installano, usa la lista dei permessi solo per cose innocue (test, lint, build) e non dare mai all'agente credenziali di produzione nell'ambiente.

Server MCP di terze parti

I server MCP estendono ciò che l'agente può fare: leggere il tuo database, chiamare API, controllare il browser. Ognuno è codice che gira con i tuoi permessi e le cui descrizioni degli strumenti il modello legge come istruzioni. Installa solo server di fonti che conosci, controlla cosa chiedono, preferisci quelli che funzionano con credenziali in sola lettura e sorveglia i cambi di configurazione: un server che cambia la sua definizione dopo che l'hai approvato è un campanello d'allarme.

File di regole di repository altrui

I file di regole (.cursor/rules, .cursorrules) sono istruzioni che il modello segue a ogni richiesta. Se cloni un repository, un template o un esempio da internet, può portarsi dietro regole che non vedi a colpo d'occhio, perfino con caratteri invisibili che nascondono istruzioni per infilare codice malevolo. Apri e leggi i file di regole di qualsiasi progetto che non hai scritto tu prima di lasciare che l'agente ci lavori.

Tieni Cursor aggiornato

Come qualsiasi editor con un agente dentro, Cursor ha avuto falle di sicurezza proprie, diverse legate alla fiducia negli spazi di lavoro e a MCP. Aggiorna quando esce una nuova versione e non aprire progetti di origine dubbia con l'esecuzione automatica attiva.

Parte 2: le falle che Cursor mette nel tuo codice

Il modello ottimizza perché il codice funzioni, non perché sia sicuro. Questi sono gli schemi che si ripetono di più nelle app scritte con Cursor e come individuarli:

• Segreti hardcoded. Per far partire in fretta un esempio, la chiave finisce nel codice o in una variabile pubblica. Cerca sk_live, service_role, AKIA e -----BEGIN nel tuo bundle. Di più in i segreti che la tua app fa trapelare nel browser.
• CORS aperto e autenticazione disattivata "per farlo funzionare". Davanti a un errore, il suggerimento tipico è riflettere qualsiasi origine o saltare il controllo di sessione. Sul momento funziona e lascia la porta aperta in produzione.
• Endpoint che si fidano del client. Route che accettano lo user_id, il ruolo o il prezzo dal corpo della richiesta senza verificarlo sul server.
• Nessun header di sicurezza. Il codice generato quasi mai aggiunge CSP, HSTS o X-Frame-Options; controlla con il verificatore di header.
• Dipendenze vecchie. Il modello propone le versioni che conosce, non le ultime. Esegui npm audit prima del deploy.

Un blocco di regole di sicurezza per il tuo progetto

La cosa più redditizia che puoi fare è dire al modello, una volta per tutte, cosa non deve fare. Incolla questo in .cursor/rules/security.mdc (o in .cursorrules) con la regola impostata per applicarsi sempre. È in inglese perché è la lingua in cui il modello obbedisce meglio:

# Security rules (always apply)
- Never hardcode API keys, tokens or passwords. Read them from
  environment variables on the server only.
- Never put secrets in variables prefixed NEXT_PUBLIC_, VITE_ or NUXT_PUBLIC_.
- Never disable authentication, authorization or Row Level Security
  to make something work. Fix the policy instead and explain why.
- CORS: allow only an explicit list of origins. Never reflect the
  request origin together with credentials.
- Validate input and authorize every API route on the server, even if
  the UI hides the action.
- Set security headers: CSP, HSTS, X-Frame-Options,
  X-Content-Type-Options, Referrer-Policy.
- Session cookies must be Secure, HttpOnly and SameSite=Lax.
- Add a dependency only when necessary, pinned to a maintained version.
- If a request conflicts with these rules, stop and explain the
  security trade-off before writing code.

Un prompt di revisione prima del deploy

Prima di ogni deploy, apri una chat nuova con tutto il progetto nel contesto e chiedigli: "Revisiona questo progetto come auditor di sicurezza prima del deploy. Elenca ogni segreto che arriva al codice client, ogni route API senza controllo di sessione o permessi, ogni regola CORS o RLS allentata, gli header di sicurezza mancanti e i cookie senza Secure, HttpOnly o SameSite. Per ogni risultato indica file, riga e correzione. Non modificare ancora il codice." Poi correggi i risultati uno a uno e richiedi la revisione.

Verifica il risultato dall'esterno

Il modello revisiona il codice che vede; quello che conta è ciò che vede un attaccante. Quando fai il deploy, lancia Scanaris sull'URL pubblico: rileva segreti nel JavaScript, CORS permissivo, header e cookie configurati male, file sensibili raggiungibili e versioni con vulnerabilità note, e ti restituisce un prompt da incollare in Cursor per ogni risultato. Se lo lasci in monitoraggio, ti avvisa quando una sessione di vibe coding riapre qualcosa che era già chiuso. Per la mappa completa, leggi la guida alla sicurezza per app create con l'IA e la checklist di lancio.

Domande frequenti

È sicuro usare Cursor con codice aziendale?

Con la modalità privacy attiva, i segreti esclusi dall'indicizzazione e senza incollare dati reali nella chat, il rischio è paragonabile a quello di qualsiasi strumento cloud. Controlla le policy della tua azienda e, se serve, usa il piano team per imporre la configurazione.

Il codice scritto da Cursor è meno sicuro di quello scritto a mano?

Non necessariamente, ma fallisce in punti prevedibili: segreti, permessi che danno fastidio e configurazione che nessuno ha chiesto. Con regole chiare e una revisione prima del deploy, il risultato è di solito migliore della media.

Cosa faccio se l'agente ha già eseguito qualcosa che non doveva?

Ruota qualsiasi credenziale a cui avesse accesso, controlla la cronologia di git e del terminale per vedere cosa ha toccato, e limita l'esecuzione automatica prima di continuare.