Cursor AI è sicuro? L’editor, il codice e l’app che hai pubblicato

Hai costruito qualcosa in Cursor, funziona, e stai per metterci sopra persone vere. A un certo punto di quella settimana hai digitato «cursor ai è sicuro» in un motore di ricerca, e quello che è uscito era una pagina sulle impostazioni di privacy di Cursor, una pagina su quanto vale il codice scritto da un’IA, e una pagina su un download di puntatori del mouse personalizzati. Nessuna ha detto una parola sull’app che stai per pubblicare.

Ecco la parte che la maggior parte di quelle risposte sbaglia: «Cursor AI è sicuro?» sono tre domande in una sola frase, e hanno tre risposte diverse. Due riguardano Cursor e i modelli che ci stanno dietro. La terza riguarda ciò che hai pubblicato, ed è quella che decide se uno sconosciuto può leggere i dati dei tuoi utenti.

Pensa a Cursor come a un’impresa edile che hai assunto per costruire una casa. Se tiene una copia dei tuoi progetti è una domanda. Se ciò che costruisce è a norma è una seconda. Se le porte si chiudono a chiave una volta che ti sei trasferito è la terza, e resta la tua domanda per tutto il tempo che ci abiti.

Cursor AI è sicuro?

Come editor, è un normale strumento cloud: un interruttore per la privacy, una pagina di sicurezza pubblicata e un’attestazione SOC 2 Type II. Questo risponde a una delle tre domande, e non a quella che decide se degli sconosciuti possono leggere i dati dei tuoi utenti.

1. L’editor. Se Cursor tiene il tuo codice, si allena su di esso o lo passa a qualcun altro. Questa è la copia dei progetti in mano all’impresa.
2. Il codice. Se ciò che l’IA scrive è sicuro. Questa è la domanda se la casa è a norma, e nessuno lo ispeziona all’ingresso.
3. L’app che hai pubblicato. Ciò che uno sconosciuto può raggiungere dalla strada: una chiave nel codice che un browser scarica, un database che risponde senza login, un file che non avrebbe mai dovuto avere un URL. Queste sono le porte.

Niente dalla parte di Cursor può rispondere alla terza. Niente dalla nostra può rispondere alle prime due.

Cursor tiene il mio codice?

Per il tempo che serve a risponderti, sì. Dopo dipende da un interruttore.

Cursor è uno strumento cloud. Quando gli chiedi qualcosa, le parti rilevanti del tuo progetto lasciano il tuo computer, vanno sui server di Cursor e passano a un fornitore di modelli (OpenAI, Anthropic, Google, il modello che hai scelto) per essere elaborate. Il prodotto funziona così. I progetti devono arrivare all’impresa.

Quello che succede dopo è l’interruttore, e la pagina sull’uso dei dati di Cursor mette le due posizioni nello stesso paragrafo. Con il Privacy Mode acceso, «i dati dei clienti non saranno usati da Cursor per l’addestramento» e Cursor «mantiene accordi di ritenzione zero dei dati (ZDR) con tutti i fornitori», cioè le aziende che fanno girare i modelli si impegnano a non tenere nulla. Con il Privacy Mode spento, Cursor «può usare e conservare dati della codebase, prompt, azioni nell’editor, frammenti di codice e altri dati e azioni sul codice per migliorare le nostre funzioni di IA e addestrare i nostri modelli».

L’interruttore è disponibile in ogni piano, gratuito compreso, e un amministratore di team o enterprise può accenderlo per tutti e impedire ai membri di spegnerlo. La stessa guida all’hardening di Cursor dice che è acceso di default sugli account Enterprise. In un piano individuale è un’impostazione, e quell’impostazione vale la pena cercarla oggi.

Una cosa in più, perché ha già colto qualcuno di sorpresa. Da metà 2025 esistono due versioni: «Privacy Mode», che lascia che Cursor conservi alcuni dati per funzioni come i suoi agenti cloud e le memorie, e «Privacy Mode (Legacy)», che non conserva nulla. A luglio 2026 un utente di Hacker News ha raccontato di aver fatto il login nell’app iOS e di aver trovato il suo account spostato dall’impostazione Legacy a quella attuale. Un dipendente di Cursor ha risposto che il messaggio per attivare gli agenti cloud aveva fatto lo spostamento «senza chiarire cosa significasse o che è difficile da annullare», e che tornare indietro non era possibile nell’app. Se avevi scelto la più rigida, controlla che sia ancora selezionata.

Le certificazioni rispondono a una domanda più stretta di quanto sembri. La pagina di sicurezza di Cursor elenca un’attestazione SOC 2 Type II, ISO/IEC 27001 e ISO/IEC 42001. Significano che un revisore esterno ha verificato che Cursor ha controlli su come tratta i dati che detiene, nello stesso modo in cui il certificato di assicurazione di un’impresa dice che l’impresa è assicurata. Non dicono nulla sul codice che scrive né sull’app che pubblichi con esso.

Cosa carica l’indicizzazione del codice?

Un indice del tuo progetto, conservato sui server di Cursor, con i percorsi dei file cifrati e il codice in sé mai conservato come testo leggibile.

L’indicizzazione è il modo in cui Cursor risponde a una domanda sull’intero progetto e non solo sul file che hai aperto. Spezza i tuoi file in pezzi, li manda ai server di Cursor perché diventino embedding (un riassunto numerico di ciò di cui parla ogni pezzo), e conserva quegli embedding così che, quando chiedi «dove gestiamo i rimborsi», trovi i pezzi giusti. La documentazione di Cursor dice: «I percorsi dei file vengono cifrati prima di essere inviati ai server di Cursor. Il contenuto del codice non viene mai conservato in chiaro». Ciò che resta dalla loro parte è una mappa del tuo codice, ed è una cosa diversa da una copia.

Due cose vale la pena sapere sulla mappa.

Alcuni file restano fuori di default, e puoi aggiungerne altri. Cursor salta tutto ciò che è nel tuo .gitignore e una lista di default che include .env*, il file in cui di solito vivono le tue chiavi segrete. Un file .cursorignore nella radice del progetto, scritto con la stessa sintassi di .gitignore, tiene qualsiasi altra cosa tu nomini fuori dall’indice e fuori da ciò che viene mostrato all’IA.

Il terminale dell’agente non legge quella lista. Questa è la riserva che conta per le chiavi. La pagina sui file di esclusione di Cursor dice che «gli strumenti di terminale e di server MCP usati dall’Agente non possono bloccare l’accesso al codice regolato da .cursorignore», e che «una protezione completa non è garantita a causa dell’imprevedibilità degli LLM». Quando l’agente esegue un comando sulla tua macchina, può leggere .env come può farlo qualsiasi comando. Il file è fuori dall’indice e ancora a portata di mano. Se una chiave sta nella cartella di progetto che hai aperto in Cursor, trattala come una chiave che l’agente può vedere.

Il codice che scrive Cursor è sicuro?

Non di default, e questo è misurato, anche se la misura riguarda i modelli che Cursor usa e non Cursor in sé.

Veracode, un’azienda che vende test di sicurezza del codice, ha fatto passare oltre 150 modelli per gli stessi 80 compiti di programmazione, in quattro linguaggi, ognuno con un modo sicuro e uno insicuro di svolgerlo. Il suo aggiornamento di primavera 2026, pubblicato il 24 marzo 2026, ha trovato che solo il 55% dei risultati era sicuro, una cifra che Veracode definisce «praticamente identica a dove stavano due anni fa», mentre la quota che compilava aveva superato il 95%. Su due dei quattro tipi di falla i modelli non hanno quasi mai scelto la versione sicura: il cross-site scripting, che lascia che il testo di un visitatore venga eseguito come codice nel browser di un altro, è passato il 15% delle volte, e la log injection il 13%.

Il riassunto di Veracode è che i modelli «sono diventati eccellenti nello scrivere codice che compila. Hanno fallito nello scrivere codice che è sicuro».

Per te, la persona che il codice non l’ha scritto, il divario tra quei due numeri è tutto il risultato. Il test che fai su un progetto Cursor è se funziona: clicchi in giro per l’app e compaiono le cose giuste. Quello è il 95%. Il test che nessuno fa è se il codice ha deciso chi può vedere cosa, e il 55% dice che quella decisione è stata presa circa la metà delle volte. Un’app può superare del tutto il primo test e fallire il secondo, perché una pagina che ti mostra i tuoi ordini e una pagina che mostra a chiunque gli ordini di tutti sembrano identiche alla persona a cui appartiene l’account.

Dove va presa quella decisione, e perché «carica gli ordini» non la prende mai da sola, è al centro della guida a Cursor.

Prompt injection, in parole semplici

Il modello tratta le istruzioni come istruzioni ovunque le trovi, anche dentro cose che doveva soltanto leggere.

Dici a Cursor «riassumi questo thread» o «metti in ordine questo file», e per farlo legge il thread o il file. Se il thread contiene una frase scritta per sembrare un’istruzione a un’IA, il modello potrebbe seguirla, perché non ha un modo affidabile di distinguere la tua voce da quella della pagina. Questa è la prompt injection, e in un agente di programmazione, che può modificare file ed eseguire comandi sulla tua macchina, le conseguenze vanno oltre un brutto riassunto.

Due casi con un nome, entrambi contro Cursor. A marzo 2025 Pillar Security ha pubblicato «Rules File Backdoor»: istruzioni nascoste con caratteri Unicode invisibili dentro un file .cursor/rules, il file di configurazione che dice a Cursor come vuoi che il tuo codice sia scritto. Il file sembrava pulito nell’editor e in un diff di GitHub, e diceva in silenzio all’IA di aggiungere a ogni pagina generata uno script dal dominio di un attaccante e di non menzionarlo mai. La risposta di Cursor è stata che non si trattava di una vulnerabilità della sua piattaforma e che la responsabilità è dell’utente. Ad agosto 2025 Aim Security ha reso nota CVE-2025-54135, che hanno chiamato CurXecute: un messaggio in un canale Slack pubblico, letto da Cursor attraverso un server MCP (un plug-in che permette all’agente di raggiungere strumenti esterni), poteva far scrivere all’agente una voce nella sua stessa configurazione mcp.json, e Cursor avviava quella voce, eseguendo il comando dell’attaccante, prima che tu avessi approvato la modifica. Cursor l’ha corretta nella versione 1.3 il 29 luglio 2025, e ora ogni modifica a quel file aspetta la tua approvazione.

Ciò che ne segue per te è breve. Un file di regole che hai copiato da un repository o da un articolo è codice, e guida tutto ciò che l’agente scrive dopo, quindi leggilo come codice. Tieni Cursor aggiornato, dato che la correzione di CurXecute era un numero di versione. E ogni server MCP che colleghi e che legge testo dall’esterno, una casella di posta, una coda di ticket, una ricerca, consegna all’agente frasi che tu non hai scritto.

Cosa dice una scansione di 30.998 app online sulla terza domanda

Che niente dell’editor arriva all’app che hai pubblicato. Non sappiamo distinguere dall’esterno un’app fatta con Cursor da qualsiasi altra, e il risultato è questo.

Tra il 12 e il 14 agosto 2026 abbiamo passato i nove controlli esterni che chiunque può lanciare gratis sulla nostra home page su 30.998 app online. Le abbiamo trovate da dove erano pubblicate: 18.554 sul dominio di Lovable, 5.438 su quello di Base44, 3.042 su quello di Replit, e così via. Un progetto Cursor viene deployato dove lo metti tu, su Vercel, su Netlify, su un dominio che hai comprato, e la pagina che un visitatore scarica non porta alcun segno dell’editor che l’ha scritta. Quindi non c’è una colonna Cursor nel report, e non può esserci.

Quello che c’è, su ogni builder che abbiamo misurato, è la stessa breve lista di cose che un proprietario ha lasciato aperte, e nessuna la decide l’editor. Ogni quota qui sotto è sulle app in cui quel controllo ha risposto, perché un controllo che non è riuscito a finire è sconosciuto e non superato. Nessuna app viene nominata qui né altrove tra ciò che pubblichiamo.

La prima riga è misurata sulle 3.680 app che nominavano un progetto Supabase e il cui database ha risposto alla domanda, per questo la sua base è più piccola; cosa legge quel controllo e cosa no ha tutta la scala. La quinta riga è quella che costa denaro da sola: una chiave segreta di OpenAI, Anthropic, AWS o Stripe, o una chiave service_role di Supabase, nel codice che un browser scarica.

L’ultima colonna è ciò che cambia con Cursor. Sul dominio di un builder, due di quelle righe appartengono all’host: gli header li manda ciò che serve la pagina, e le source map seguono le impostazioni di build del builder. Un progetto Cursor è il tuo repository, la tua build e il tuo deploy, quindi ogni riga di quella tabella è tua, comprese le due che un proprietario Lovable non controlla. È più controllo e più da verificare, ed è il motivo per cui la guida a Cursor dedica il suo tempo all’output della tua build e al tuo database invece che all’editor. L’articolo su Replit pone le stesse tre domande a una piattaforma che ospita l’app e allo stesso tempo ti lascia pubblicare un server tuo.

Il controllo di cinque minuti dall’esterno

Usa una finestra privata per i primi tre, così il tuo login non risponde al posto di uno sconosciuto.

1. Apri il tuo indirizzo pubblicato con /.env in fondo, poi con /.git/config. Entrambi devono fallire. Se uno mostra del testo, ruota oggi ogni chiave che contiene, poi sistema il deploy perché quel file non venga mai servito.
2. Apri allo stesso modo una delle tue route API, una che non vorresti far leggere a uno sconosciuto. Se risponde con dei dati, quella route ha bisogno di un controllo del login.
3. Apri la tua app online, poi la scheda Sources degli strumenti per sviluppatori del browser. Se riesci a leggere i tuoi file originali con i commenti, le source map sono attive nella tua build di produzione.
4. Se i tuoi dati sono in Supabase, la metà interna del controllo sta nella guida a Cursor: cerca service_role e sk_live_ nell’output della build, poi apri la pagina delle policy.
5. Oppure lascia che lo faccia la scansione. Esegue questi e il resto dei nove dall’esterno, ci mette circa 20 secondi, non ha bisogno di un account e stampa «Impossibile controllare» per tutto ciò a cui non ha potuto rispondere, invece di una spunta: scansiona la tua app.

Cosa cambia dopo il prossimo push?

Qualsiasi cosa. Un progetto Cursor va online quando fai push, e niente tra il tuo editor e internet rilegge l’app in cerca di una route che ha perso il suo controllo del login, di una chiave incollata a mezzanotte per superare una build che falliva, o di una source map tornata attiva con una modifica di configurazione. Il numero di Veracode è il motivo per cui qui conta più che su un builder: ogni sessione con l’agente è codice nuovo che compila e potrebbe non essere sicuro, e una scansione fatta il mese scorso descrive l’app del mese scorso.

Reeve Monitor è fatto per questo. Rilancia tutti e nove i controlli ogni ora su fino a tre app, controlla la disponibilità ogni 60 secondi, ti avvisa quando un risultato cambia invece di aspettare che tu vada a guardare, e manda un report mensile. Costa €12 al mese a listino, con sette giorni gratis prima di addebitarti qualcosa; la pagina dei prezzi a volte è sotto la cifra indicata qui e mai sopra. Monitor osserva e nient’altro. Se la tua app Cursor tiene i suoi dati in Supabase, Care è il piano che conserva anche una copia di quel database, e dei tuoi file caricati una volta che colleghi una credenziale Storage. Se i dati vivono altrove, Monitor è la metà che calza.

Cosa fare questa settimana

La metà interna di tutto questo, l’output della build e il database, è la guida a Cursor. La checklist di sicurezza da 10 minuti copre ciò che vale la pena confermare su qualsiasi app appena lanciata, chiunque l’abbia scritta.