Il codice generato da Cursor compila. Ma chi può davvero vedere i dati?

Il codice generato dall’AI può compilare e restare pericoloso

Un codice può compilare, superare i test principali e avere una struttura apparentemente ordinata. Questo non significa che stia proteggendo correttamente i dati degli utenti.

È il punto emerso dalla notizia “AI-generated Rust compiles perfectly. That’s the scary part.”: nel lavoro su componenti di sicurezza come AppArmor e snap-confine, il problema non è più soltanto generare codice che parte. Il problema è dimostrare che il nuovo codice conserva davvero il comportamento corretto e non introduce differenze pericolose.

Per chi ha spedito un’app costruita con Cursor, la traduzione è semplice: “funziona” non è ancora un verdetto.

Cosa significa se il tuo codice l’ha scritto Cursor

Nel vibe-coding il percorso tipico è rapido: descrivi una feature, Cursor modifica più file, esegue qualche test, corregge gli errori e ti lascia una pull request pronta da provare.

Il rischio non è aver usato Cursor. Il rischio è confondere la correttezza locale con la sicurezza del flusso completo.

Prendi un caso concreto: una dashboard con ordini, fatture o documenti privati. Cursor può generare un endpoint come questo, concettualmente corretto:

GET /api/orders/{order_id}

L’endpoint risponde. Il database restituisce l’ordine. Il test con l’utente proprietario passa.

Ma cosa succede se un utente autenticato cambia {order_id} con l’identificativo di un altro cliente?

Se il backend verifica soltanto che l’utente abbia effettuato il login, ma non controlla che quell’ordine appartenga davvero a quell’utente, hai un IDOR: accesso a un oggetto tramite un identificatore prevedibile o manipolabile.

Non è un errore di sintassi. Non è necessariamente un errore che il linter segnala. È un errore nel rapporto tra identità, risorsa e autorizzazione.

Perché ora ti serve un audit del repo

Quando un repo cresce veloce, il problema non è contare quante righe ha scritto l’AI. È capire se le regole importanti sono applicate lungo ogni percorso che porta ai dati.

Un audit serve proprio a trasformare questa domanda vaga — “sembra sicuro?” — in un risultato operativo: un verdetto sul rischio e, quando il piano lo prevede, evidenze localizzate nel repo.

Per un possibile IDOR, l’analisi deve collegare più elementi:

• come viene autenticato l’utente;
• da quale token o sessione viene ricavata la sua identità;
• come viene ricevuto l’identificativo della risorsa;
• quale query viene eseguita sul database;
• se la query filtra anche per user_id, tenant_id o equivalente;
• se esistono endpoint alternativi che restituiscono la stessa risorsa;
• se il controllo resta valido anche per ruoli diversi, endpoint amministrativi e accessi indiretti.

Guardare un singolo file spesso non basta. Un controllo presente nella pagina frontend non protegge il backend. Un middleware globale può non coprire una route aggiunta dopo. Una query corretta può essere aggirata da un endpoint secondario che usa lo stesso modello senza lo stesso filtro.

L’audit non parte dal presupposto che chi ha usato Cursor abbia lavorato male. Parte dal presupposto che la velocità di generazione abbia reso più difficile mantenere una visione completa del sistema.

Il risultato che ti serve non è una lista infinita di osservazioni. Ti serve sapere se esiste un buco concreto, quanto è esposto e quali evidenze del repo lo dimostrano.

Cosa un linter non vede

Un linter è utile per errori di forma e pattern locali: variabili inutilizzate, tipi incoerenti, import non validi, regole stilistiche o alcune classi note di vulnerabilità.

Ma un linter normalmente non sa qual è il proprietario legittimo di un ordine. Non conosce il modello di autorizzazione del tuo prodotto. Non sa che tenant_id deve arrivare dalla sessione e non dalla richiesta dell’utente. Non ricostruisce necessariamente il percorso tra frontend, API, ORM, policy e database.

Può anche vedere una query formalmente valida come:

SELECT * FROM orders WHERE id = :order_id;

Quella query non è “sbagliata” dal punto di vista SQL. È sbagliata se l’applicazione deve impedire che un cliente legga l’ordine di un altro.

Lo stesso vale per altri problemi di comportamento: webhook accettati senza verifica della firma, segreti esposti nel bundle frontend, controlli di ruolo applicati solo in una route, dati restituiti in un endpoint di export ma protetti nell’interfaccia principale.

Il linter controlla il codice che riesce a classificare. L’audit prova a ricostruire cosa può succedere quando il codice viene usato davvero, con identità, dati, ruoli e percorsi diversi.

Il verdetto conta più della rassicurazione

Il nemico non è Cursor. Il nemico è spedire senza sapere.

Un audit on-demand prende il tuo ZIP, analizza il repo con specialisti AI e restituisce un PDF con un verdetto. Non è un pentest, non è un linter e non modifica il codice. Non certifica che tutto sia sicuro e non promette il 100%.

La differenza è il tipo di output: non una sensazione positiva perché la build è verde, ma una decisione documentata sul rischio osservato nel perimetro analizzato.

Per un repo vibe-coded con accesso a dati privati, il piano sensato è quello che porta evidenze su file, righe e comportamento. Se il problema è tecnico e vuoi capire dove intervenire, scegli il Diagnostic: score, file, righe ed evidenze, senza fix automatici e senza revisione umana inclusa.

Lo Snapshot è adatto quando non sai ancora se esiste un problema e vuoi soltanto uno score iniziale. Non include file o righe.

Cosa fare questa settimana

1. Elenca le risorse che contengono dati di altri utenti: ordini, fatture, documenti, messaggi, allegati.
2. Per ogni endpoint che riceve un ID, verifica che l’autorizzazione sia collegata al proprietario della risorsa.
3. Prova manualmente due identità diverse: l’utente A deve ricevere un rifiuto quando chiede la risorsa dell’utente B.
4. Cerca endpoint duplicati: export, download, preview, admin, webhook e route legacy.
5. Controlla che i test coprano almeno un caso di accesso tra tenant o utenti diversi.
6. Congela il commit che vuoi mettere online e sottoponilo a un audit prima del prossimo go-live.

Se hai spedito con Cursor e vuoi passare da “compila” a “so cosa sto spedendo”, carica il repo su VibeInspect.ai. Riceverai un audit on-demand in PDF: sorgente cancellato a fine analisi, niente server da installare.

FAQ

Un IDOR può esistere anche se uso un framework moderno?

Sì. Il framework può offrire middleware e policy, ma l’autorizzazione corretta dipende da come colleghi identità, risorse e query nel tuo progetto.

Cursor può individuare un IDOR?

Può aiutarti a cercarlo e a scrivere test o controlli. Non devi però trattare la sua autovalutazione come un verdetto indipendente sul repo.

Un linter sostituisce un audit?

No. Il linter è un controllo automatico utile, ma non ricostruisce sempre i flussi di autorizzazione e il comportamento tra più componenti.

Quale piano VibeInspect scegliere per un possibile IDOR?

Il Diagnostic, perché un buco tecnico richiede evidenze su file, righe e percorso del problema.