Cursor è sicuro da usare? Rischi, controlli e best practice

Cos'è Cursor e perché cambia il modello di sicurezza?

Cursor è un editor di codice AI-first, un fork di VS Code ricostruito attorno al modello anziché attorno al file. Funziona dentro il normale flusso dello sviluppatore (l'editor, il terminale integrato, il pannello dell'agente) e agisce su istruzioni in linguaggio naturale: spiega questo codebase, costruisci questa funzionalità, correggi questo test che fallisce, fai refactoring su questi file. Per farlo bene indicizza il repository così che il modello abbia contesto, modifica più file in una singola esecuzione dell'agente, esegue task e comandi del terminale, e si estende tramite il Model Context Protocol (MCP) per raggiungere database, sistemi di tracciamento delle issue e tooling interno.

Quella combinazione è ciò che rompe il vecchio modello di sicurezza. Un assistente IDE classico offriva un completamento; un essere umano lo leggeva e sceglieva se accettare o rifiutare. Il raggio d'azione di un suggerimento sbagliato era un singolo blocco di codice che uno sviluppatore doveva comunque incollare. Cursor invece compie azioni. Legge file che non hai mai nominato, esegue comandi che non hai mai digitato, riscrive codice in tutto l'albero e può eseguire un task nel momento in cui apri una cartella. La superficie di attacco non è più "cosa ha suggerito il modello". È "cosa può fare questo editor con l'accesso che ha, quanto codice può generare in volume, e chi può influenzare le sue istruzioni".

“

Un suggerimento è una bozza che un essere umano sceglie di accettare. Un'azione è una cosa già accaduta. Il modello di sicurezza deve passare dalla revisione di bozze al vincolo delle azioni.

C'è un secondo cambiamento, e riguarda la velocità. La pull request è diventata la casa della sicurezza applicativa perché si collocava al ritmo umano: una persona rallentava, leggeva il diff e solo allora faceva il merge. Cursor non lavora al ritmo umano. Una singola sessione dell'agente può produrre più codice in un pomeriggio di quanto un revisore ne legga in una settimana, e l'editor genererà volentieri codice funzionante che è silenziosamente insicuro. Quando ciò accade, il diff smette di essere un punto di controllo e diventa la trascrizione di decisioni già prese. Qualsiasi controllo che agisca solo alla pull request ora sta rivedendo la storia, non prevenendola.

Per la maggior parte dei team la domanda pratica non è se Cursor abbia protezioni native. Le ha, e parecchie sono davvero buone. La domanda è se siano sufficienti per l'uso quotidiano. La risposta onesta è no. La pagina sulla sicurezza di Cursor documenta controlli reali, e questi riducono il rischio, ma un'adozione sicura dipende ancora da permessi, isolamento, supervisione umana e validazione indipendente su codice, dipendenze, segreti e pipeline.

Come funziona il modello di sicurezza di Cursor

Il modello di Cursor è costruito attorno a tre idee: dimostrare che la piattaforma gestisce i dati in modo responsabile, dare allo sviluppatore le leve per tenere il codice sensibile fuori dalla portata del modello, e contenere ciò che a un progetto aperto è consentito fare. In pratica ciò si traduce in una manciata di controlli.

È una base ragionevole, e gran parte di questo non esisteva negli assistenti IDE di una generazione fa. La trappola è leggerla come un confine di sicurezza definitivo. La Privacy Mode protegge i tuoi dati ma non dice nulla sulla sicurezza del codice che Cursor scrive. .cursorignore funziona solo se lo mantieni. Il Workspace Trust ti protegge solo se è attivo, e per gran parte della storia di Cursor non lo era. SOC 2 attesta come Cursor gestisce il suo servizio, non quanto si comporta in sicurezza sulla tua macchina. Ogni controllo qui ha un limite documentato, e la prossima sezione riguarda cosa succede quando ci si appoggia troppo su di essi.

I 6 principali rischi per la sicurezza in Cursor

I rischi qui sotto non sono teorici. Mappano a vulnerabilità divulgate, ricerche pubblicate e alla OWASP Top 10 per le applicazioni LLM. I numeri che li inquadrano sono gli stessi che ogni team AppSec sta ora citando.

1. Workspace Trust disattivato per impostazione predefinita, che porta a esecuzione silenziosa di codice

È il problema distintivo di Cursor. Nel settembre 2025, The Hacker News ha riportato una falla ("Cursor AI Code Editor Flaw Enables Silent Code Execution via Malicious Repositories") radicata nel fatto che il Workspace Trust arrivava disabilitato per impostazione predefinita. Poiché Cursor è un fork di VS Code, un progetto può portare con sé un task .vscode/tasks.json configurato con runOn: folderOpen, e con la fiducia disattivata quel task viene eseguito nell'istante in cui uno sviluppatore apre la cartella, eseguendo codice arbitrario nel contesto dell'utente.

L'attacco è banale da allestire. Un attaccante pubblica un repository allettante su GitHub, vi nasconde dentro un task di "autorun" e aspetta che qualcuno lo cloni e lo apra in Cursor. Nessun prompt, nessun clic, nessuna revisione: aprire il progetto basta per far fuoriuscire credenziali, modificare file o piantare un punto d'appoggio per una compromissione più ampia. I ricercatori (Oasis Security) hanno raccomandato la stessa mitigazione che raccomandiamo noi: abilita il Workspace Trust, apri prima i repository non attendibili in un editor diverso e verifica un progetto prima di aprirlo in Cursor. La correzione è una sola impostazione, ma aiuta solo gli sviluppatori che sanno di doverla attivare.

2. Codice insicuro generato dall'AI

Il compito di Cursor è scrivere codice in fretta, e in fretta non significa in sicurezza. Il benchmark SusVibes della Carnegie Mellon, che traccia agenti di codice commerciali tra cui Cursor, ha rilevato che la combinazione più forte di agente e modello produceva codice funzionalmente corretto nel 61% dei casi ma codice sicuro solo nel 10,5% dei casi, e che oltre l'80% delle soluzioni funzionalmente corrette presentava comunque una vulnerabilità. Il divario tra "funziona" e "è sicuro" è dove vive il pericolo: codice che supera il test e spedisce la vulnerabilità.

I pattern sono prevedibili. SQL costruito per concatenazione di stringhe anziché query parametrizzate (la classica SQL injection), prototype pollution in JavaScript, codifica dell'output mancante che apre la porta a XSS, validazione degli input assente sugli endpoint generati. Non sono bug esotici; sono i classici di OWASP, riprodotti a velocità di macchina perché il modello ha imparato da un corpus pubblico pieno di essi. Lo studio NYU "Asleep at the Keyboard" ha rilevato circa il 40% del codice generato dall'AI vulnerabile attraverso gli scenari MITRE Top-25, e Cursor è saldamente dentro quella distribuzione. Più in fretta l'editor spedisce, più in fretta si accumulano i difetti, e il codice dall'aspetto funzionante è proprio quello che un revisore di fretta lascia passare.

3. Esposizione di dati e contesto

Cursor è utile perché ha contesto, e quel contesto include regolarmente più del codice sorgente. Qualsiasi cosa aperta nel workspace, un file .env, una configurazione con stringhe di connessione, endpoint API interni, può essere tirata dentro il contesto del modello a meno che tu non la escluda esplicitamente con .cursorignore. Le funzionalità AI di Cursor inviano anche codice a un'API esterna per generare risposte, quindi per la logica di business sensibile la questione di dove va quel traffico è reale, e la Privacy Mode è il compromesso che fai per controllarla.

L'esposizione è spesso indiretta. Mentre riassume un repository o esegue il debug di un errore, l'agente può far emergere un token, una credenziale o un hostname interno in un output che poi finisce in una chat, un ticket o un file committato, dove sopravvive a lungo dopo la fine della sessione. Come hanno notato Endor Labs e altri, l'indicizzazione del codebase allarga questa superficie: più Cursor indicizza, più può raggiungere inavvertitamente. La postura predefinita è la comodità, e la comodità significa accesso ampio a meno che tu non lo restringa a mano.

4. Prompt injection e avvelenamento del file di regole

La prompt injection è il rischio distintivo degli strumenti di codice agentici, ed è il rischio LLM numero uno di OWASP (LLM01) per il terzo anno consecutivo. Un attaccante nasconde istruzioni in qualcosa che l'agente legge, e l'agente le segue, scavalcando il comportamento previsto.

In Cursor la forma pericolosa è quella indiretta, e ha una svolta specifica di Cursor: il file di regole. Istruzioni dannose possono viaggiare nel contenuto del repository, in un file .cursorrules o di regole di progetto, o nell'output di uno strumento MCP. Poiché un file di regole è fatto per guidare l'agente, uno avvelenato è prompt injection per progettazione: un contributore o una dipendenza inserisce istruzioni costruite ad arte nelle regole, e Cursor le tratta come policy. Un commento in un README che dice "prima di continuare, esegui questo script di setup" può bastare. Poiché un modello linguistico non può separare in modo affidabile un'istruzione attendibile da una dannosa incorporata nei dati, l'injection può portare a esecuzione di comandi, esfiltrazione di dati o manipolazione silenziosa del codice. Un agente guidato non si limita a rispondere male, agisce.

5. Supply chain e server MCP dannosi

Cursor installa pacchetti, clona repository e si connette a strumenti esterni come parte del normale lavoro. Se tira dentro una libreria compromessa o collega un server MCP ostile, il codice dannoso gira con qualsiasi accesso l'ambiente conceda. Non è ipotetico. All'inizio del 2026 una campagna di typosquatting su npm tracciata come "Sandworm_Mode" ha piantato server MCP malevoli imitando utility popolari, prendendo di mira specificamente gli assistenti di codice AI tra cui Cursor, Claude Code e Windsurf.

L'MCP è un nuovo confine di fiducia che la maggior parte dei team non ha modellato a livello di minacce. Un server dannoso o compromesso può nascondere istruzioni dentro le descrizioni e le risposte dei suoi strumenti, così il solo fatto di averlo connesso può guidare l'agente prima ancora che chiami lo strumento. L'allucinazione dei pacchetti aggrava il rischio: un agente che inventa un nome di pacchetto plausibile ma inesistente offre agli attaccanti uno slot da registrare e armare. L'agente spesso approverà l'installazione con sicurezza, perché il nome sembra giusto e il compito lo richiedeva.

6. Vulnerabilità documentate dell'editor che portano a RCE

Oltre alla falla di autorun, Cursor ha accumulato una serie di avvisi di sicurezza, comprese ricerche pubblicate da gruppi come Geordie AI, che coprono vettori di bypass della fiducia e di esecuzione di codice nell'editor stesso (hook Git nascosti, esecuzione persistente tramite bypass della fiducia MCP e problemi correlati). Il tema ricorrente è che Cursor è ragionevolmente sicuro come IDE, e sensibilmente insicuro come generatore automatico di codice senza un livello di revisione esterno.

Il pericolo si aggrava quando l'editor gira con ampio accesso alla macchina dello sviluppatore. Una catena di azioni singolarmente innocue, installa questa dipendenza, esegui questo task, applica questa modifica, può installare malware, alterare una configurazione CI o aprire un meccanismo di persistenza. È esattamente per questo che contano il gating della fiducia, il privilegio minimo e gli ambienti isolati, ed è per questo che la combinazione da temere è quella comune: un repo non attendibile, una configurazione permissiva per evitare attrito e un'istruzione iniettata che l'editor tratta come legittima.

Cosa copre la sicurezza nativa di Cursor, e cosa no

I controlli nativi sono reali, e conviene essere precisi sulla linea tra ciò che gestiscono e ciò che lasciano a te.

Leggi la colonna di destra come il lavoro vero e proprio. I controlli nativi di Cursor sono sbilanciati verso la privacy dei dati e la conformità del fornitore, che è dove cadono le prime domande di un acquirente. Non sono mai stati progettati per fermare un avversario determinato che controlla gli input dell'editor, e non dicono quasi nulla sulla sicurezza del codice che Cursor scrive. Tutto ciò che trasforma "Cursor è installato" in "Cursor è governato" vive nelle pratiche che seguono.

Best practice per proteggere Cursor

Queste nove pratiche colmano il divario tra la base nativa e una postura di sicurezza reale. Nessuna è esotica; la disciplina sta nell'applicarle in modo coerente in un team che si muove in fretta.

1. Abilita il Workspace Trust e tratta i repo non attendibili come ostili. Attiva il Workspace Trust come parte standard del setup, così che una cartella aperta non possa eseguire automaticamente un task. Apri prima i repository che non hai scritto in un ambiente sandbox o in un editor diverso, verifica .vscode/tasks.json e qualsiasi hook Git prima di concedere loro fiducia, e non navigare mai un allettante repo pubblico nella tua istanza Cursor primaria senza controllare cosa gli è consentito eseguire.

2. Tieni la Privacy Mode attiva per il lavoro sensibile, e fai tuo il compromesso. La Privacy Mode è il controllo che impedisce che il tuo codice venga memorizzato o usato per l'addestramento. Trattala come predefinita per qualsiasi repository con logica di business reale, dati regolamentati o codice proprietario. Quando un team sceglie di disattivarla per una funzionalità, rendilo una decisione esplicita e documentata limitata al lavoro a bassa sensibilità, non una predefinita silenziosa che tutti hanno dimenticato di controllare.

3. Cura .cursorignore come un artefatto di sicurezza. Escludi file .env, store di credenziali, configurazioni dell'infrastruttura, stringhe di connessione e qualsiasi modulo sensibile sia dal contesto AI sia dall'indicizzazione. Rivedi il file ignore come rivedi il controllo degli accessi: secondo una pianificazione, dopo ogni nuovo segreto o servizio aggiunto e come parte dell'onboarding di un nuovo repo. Un .cursorignore non aggiornato è il modo più comune con cui un segreto finisce nel contesto di un modello.

4. Mantieni un essere umano nel ciclo sul codice generato. Tratta l'output di Cursor come una bozza, non come un'implementazione finita. Indirizza tutto il codice generato o modificato attraverso la revisione delle pull request e i test automatizzati, con scrutinio extra su autenticazione, validazione degli input, query SQL e percorsi privilegiati, proprio le aree in cui i dati di SusVibes mostrano il modello sbagliare. Il punto non è la sfiducia nello strumento; è che un editor che produce migliaia di righe al giorno genera difetti sottili più in fretta di quanto emergano da soli.

5. Analizza il codice generato dall'AI con SAST in CI. Poiché solo una piccola frazione delle soluzioni AI è sicura per impostazione predefinita, un gate di analisi statica non è opzionale. Esegui SAST su ogni pull request, fai fallire la build sui risultati ad alta severità (SQL injection, XSS, prototype pollution, autorizzazione mancante) e rimanda i risultati agli sviluppatori così che le stesse classi smettano di ripresentarsi. I test funzionali non coglieranno un endpoint vulnerabile ma funzionante; solo un controllo consapevole della sicurezza lo farà.

6. Governa dipendenze, pacchetti e server MCP. Limita le installazioni a registry attendibili o mirror interni, richiedi l'approvazione per i nuovi pacchetti e analizza tutto con la software composition analysis. Verifica ogni server MCP come un confine di fiducia: usa quelli che hai scritto tu o di cui ti fidi davvero, limita ciascuno ai dati e alle azioni più ristretti di cui necessita, e mantieni un inventario così che un pacchetto soggetto a typosquatting come i server "Sandworm_Mode" non si infili inosservato.

7. Tieni i segreti fuori portata. Tieni i segreti in chiaro fuori dal workspace che l'agente può vedere. Usa un vault e iniettali a runtime, oscura i valori sensibili nei log e nell'output, e non lasciare mai file di credenziali dove l'indicizzazione di Cursor può raggiungerli. Se un segreto compare mai in una trascrizione, un file generato o un commit, ruotalo immediatamente e indaga su come ci è arrivato.

8. Esegui il lavoro rischioso in ambienti isolati a privilegio minimo. Usa container o VM sandbox per il lavoro assistito dall'AI su codice non attendibile, esegui Cursor senza privilegi elevati e blocca le connessioni in uscita non approvate così che una sessione compromessa non possa esfiltrare. Segmenta gli ambienti per sensibilità così che il lavoro ad alto rischio sia contenuto e il raggio d'azione di una singola compromissione resti piccolo.

9. Imposta la policy per sensibilità di repository e ambiente. Classifica i repository (pubblici, interni, regolamentati, di produzione) e applica controlli più rigidi a quelli sensibili: Privacy Mode attiva, indicizzazione limitata, egress ristretto, revisione più robusta richiesta. Per i sistemi critici, usa Cursor solo in ambienti senza percorso diretto verso le credenziali di produzione, e documenta la policy così che gli sviluppatori sappiano dove l'aiuto dell'AI è consentito e sotto quali vincoli.

Dove si fermano i controlli nativi: proteggere l'agente al momento del prompt

Ripercorri i rischi ed emerge uno schema. Workspace Trust, Privacy Mode, .cursorignore e SAST agiscono tutti su ciò che l'editor ha già deciso di fare, o su codice che ha già scritto. Si raggruppano attorno alla pull request, perché è lì che l'AppSec ha sempre vissuto. Ma la PR è stata un punto di controllo solo perché un essere umano la leggeva, e al ritmo dell'agente nessuno la legge più dall'inizio alla fine.

Il luogo dove imporre una regola non è più il diff; è il prompt, prima che la riga insicura venga scritta. Qualunque regola tu voglia che Cursor segua deve essere nelle sue mani nel momento in cui scrive, non in attesa in uno scanner che arriva quando il codice è già su disco e l'agente è già passato al compito successivo.

È questo il livello che aggiunge VibeDefend. È una CLI npm gratuita che si installa in circa cinque secondi e collega Cursor (oltre a Claude Code, OpenAI Codex, Windsurf e VS Code Copilot) a quattro livelli di governance che girano dentro il loop dell'agente.

Regole di business Le convenzioni del tuo repo che non sono mai state messe per iscritto (usa Decimal128 per il denaro, l'autorizzazione passa per requireOwner). VibeDefend le estrae dal modo in cui il tuo team già scrive codice e le carica nel contesto di Cursor prima di ogni modifica. Regole di sicurezza OWASP Top 10, SOC 2, GDPR e ISO 27001, caricate il giorno in cui installi. L'agente legge il promemoria applicabile prima di scrivere, così il requisito del framework diventa parte del codice anziché una casella da spuntare al momento dell'audit. Action Guard Le chiamate distruttive (un sudo rm -rf, una lettura grezza di una variabile d'ambiente che sembra un segreto, un psql ad hoc contro un host di produzione) vengono intercettate prima che partano. Avvisa o blocca per regola, con ogni intercettazione nell'audit trail. Live Findings Ogni risultato dei suoi scanner (SAST con reachability, SCA, segreti, IaC e CI/CD) è live nel contesto di Cursor, così non si limita a scrivere codice sicuro, smista e corregge le vulnerabilità che hai già.

In modo cruciale, nulla del tuo codice attraversa la rete. Le decisioni avvengono localmente accanto all'agente; solo metadati di governance strutturati (la regola che è scattata, il percorso del file, la severità, un timestamp) raggiungono il backend. Le regioni EU e US sono fisicamente separate, e scegli la regione al momento dell'installazione. Quel modello di privacy è ciò che permette a un controllo di stare così vicino al codice senza diventare a sua volta un rischio di esfiltrazione dei dati, la stessa preoccupazione che rende la Privacy Mode di Cursor un compromesso.

Questo non sostituisce le pratiche di cui sopra. È il livello mancante che esse danno per esistente: quello che mette le tue regole nelle mani di Cursor al momento del prompt, così che la riga insicura venga riscritta prima ancora di essere suggerita, anziché colta tre fasi più tardi da uno scanner che legge un diff che nessuno ha avuto tempo di leggere. Il Workspace Trust impedisce all'editor di fare ciò che non deve fare; VibeDefend modella ciò che scrive in primo luogo.

Domande frequenti

Cursor è sicuro?

Cursor è sicuro da usare quando è configurato e contenuto, e rischioso quando non lo è. La sua conformità SOC 2 Type II, la Privacy Mode, .cursorignore e il Workspace Trust prevengono una classe reale di fughe di dati e incidenti. Il rischio residuo viene dalle impostazioni predefinite (Workspace Trust storicamente disattivato, indicizzazione ampia), dal codice che genera (solo una piccola frazione è sicura pronta all'uso), dagli input (prompt injection, file di regole avvelenati, server MCP dannosi) e dall'ambiente circostante (segreti esposti, repo non attendibili). Trattalo come un agente potente che ha bisogno di gating della fiducia, esclusione dei segreti, revisione umana e SAST, non come uno strumento sicuro per impostazione predefinita.

Cursor invia il mio codice al cloud?

Sì. Le funzionalità AI di Cursor inviano codice a un'API esterna per generare risposte, il che può includere contenuti dei file e il contesto circostante del tuo compito. La Privacy Mode cambia cosa succede a quel codice dal lato di Cursor: con essa attiva, il tuo codice non viene memorizzato né usato per addestrare modelli. Per la logica di business sensibile, tieni la Privacy Mode abilitata, escludi segreti e dati regolamentati dal contesto con .cursorignore, e confronta la policy di gestione dei dati di Cursor su cursor.com/security con i tuoi requisiti.

Cos'è .cursorignore e perché conta?

.cursorignore è un file (simile nello spirito a .gitignore) che dice a Cursor quali percorsi escludere dal contesto dell'AI e dall'indicizzazione del codebase. Conta perché, per impostazione predefinita, qualsiasi cosa aperta nel workspace può essere tirata dentro il contesto del modello, compresi file .env, configurazioni e stringhe di connessione. Un .cursorignore ben mantenuto è la leva principale che tiene segreti e moduli sensibili fuori dalla portata del modello. Uno non aggiornato è il modo più comune con cui una credenziale finisce in una richiesta AI.

Dovrei abilitare il Workspace Trust in Cursor?

Sì. Il Workspace Trust subordina le funzionalità di esecuzione di codice di una cartella aperta a una decisione esplicita di fiducia. È la mitigazione diretta della falla del settembre 2025 in cui un repository trappola poteva eseguire automaticamente un task ed eseguire codice nel momento in cui aprivi la cartella. Poiché Cursor storicamente arrivava con il Workspace Trust disabilitato per impostazione predefinita, abilitarlo dovrebbe essere parte standard del tuo setup. Abbinalo all'apertura dei repository non attendibili prima in una sandbox o in un editor diverso.

Cursor può eseguire automaticamente codice da un repository?

Può, se il Workspace Trust è disattivato. Essendo un fork di VS Code, Cursor onora i task configurati con runOn: folderOpen, quindi un .vscode/tasks.json dannoso in un repository che cloni e apri può eseguirsi immediatamente, senza prompt, nel tuo contesto utente. Questa era la base della falla di esecuzione silenziosa di codice riportata nel settembre 2025. Abilitare il Workspace Trust chiude il divario, ma il comportamento predefinito è il motivo per cui non dovresti mai aprire un progetto non attendibile nella tua istanza Cursor primaria.

La Privacy Mode di Cursor lo rende sicuro?

No, ed è importante essere precisi qui. La Privacy Mode è un controllo sui dati: garantisce che il tuo codice non venga memorizzato sui server di Cursor né usato per l'addestramento. Non dice nulla sulla sicurezza del codice che Cursor genera, sul fatto che un repo possa eseguire automaticamente un task, sul fatto che una prompt injection possa guidare l'agente, o sul fatto che un server MCP sia dannoso. La Privacy Mode protegge i tuoi dati; non protegge la tua applicazione. Hai ancora bisogno di Workspace Trust, .cursorignore, SAST, revisione umana e un controllo al momento del prompt.

In cosa la sicurezza di Cursor è diversa da Claude Code, GitHub Copilot o Codex?

I fondamentali sono condivisi (privilegio minimo, esclusione dei segreti, revisione umana, scansione delle dipendenze), ma le superfici differiscono. I problemi distintivi di Cursor sono il Workspace Trust che arrivava disattivato per impostazione predefinita e un alto tasso di codice generato insicuro; quello di Claude Code è la profonda integrazione con MCP e shell; quello di GitHub Copilot sono suggerimenti insicuri e fuoriuscita di segreti su larga scala; quello di Codex sono incidenti di command injection e supply chain. Copriamo ogni agente nella sua guida: Claude Code, GitHub Copilot e OpenAI Codex.