Il tuo repo Cursor può avere un IDOR anche se tutto compila

Un modello più forte non basta: serve sapere cosa succede nel tuo repo

Anthropic ha portato il modello Mythos 5 dentro Claude Security, il servizio che analizza i repository alla ricerca di vulnerabilità e propone patch. La notizia arriva da “Anthropic brings Mythos 5 to its Claude Security vulnerability scanner”, pubblicato da The New Stack il 21 agosto 2026.

Il dettaglio importante non è soltanto che un modello molto capace possa trovare più problemi. È il modo in cui viene utilizzato: il modello resta dentro uno strumento controllato e restituisce risultati difensivi, come alert e patch, invece di offrire accesso diretto alle sue capacità.

Per il founder che ha costruito e spedito un prodotto con Cursor, questa è una distinzione concreta. Non ti serve un’altra demo di AI che scrive codice. Ti serve sapere se il codice che hai già messo online lascia a un utente la possibilità di leggere o modificare dati che non gli appartengono.

Cosa significa se il tuo codice l’ha scritto Cursor

Prendiamo un buco preciso: l’IDOR, cioè Insecure Direct Object Reference. Succede quando un endpoint usa un identificatore fornito dal client senza verificare che l’utente autenticato abbia davvero il diritto di accedere a quell’oggetto.

Esempio tipico: il tuo SaaS espone una rotta come /api/invoices/1842. L’utente vede la propria fattura, cambia 1842 in 1843 e il server restituisce il documento di un altro account. Oppure modifica un project_id, un workspace_id o un user_id in una richiesta e ottiene dati fuori dal proprio perimetro.

Cursor può aiutarti a generare velocemente il frontend, le API, lo schema del database e il middleware di autenticazione. Può anche aggiungere test che dimostrano che “un utente può leggere la propria fattura”. Il rischio è che manchi il test decisivo: “un utente non può leggere la fattura di un altro utente, anche se conosce l’ID”.

Il codice può compilare. I test possono passare. Il login può funzionare. Eppure l’autorizzazione sugli oggetti può essere assente in uno solo degli endpoint critici.

Questa è la differenza tra autenticazione e autorizzazione. L’autenticazione risponde a “chi sei?”. L’autorizzazione risponde a “puoi accedere proprio a questa risorsa?”. Nei repository generati rapidamente, la prima è spesso visibile. La seconda è distribuita tra query, controller, policy, middleware e convenzioni che non sempre sono state applicate ovunque.

Perché ora ti serve un audit: il verdetto che manca

Quando hai usato Cursor per arrivare al go-live, probabilmente hai ottimizzato per velocità: prompt, iterazioni, anteprima, deploy. È una scelta legittima. Il problema nasce quando la velocità di produzione supera la tua capacità di verificare il comportamento del sistema.

Un audit VibeInspect serve esattamente in quel punto. Parti dal tuo ZIP repository e ottieni un verdetto sul livello di rischio del codice analizzato, con un percorso di evidenze proporzionato al piano scelto. Non devi trasformare il progetto in una nuova attività di sviluppo e non devi rileggere ogni file per tentare di ricostruire mentalmente l’architettura.

Per un possibile IDOR, il controllo non dovrebbe fermarsi alla presenza di un middleware JWT o di una pagina di login. Deve seguire il flusso completo:

• dove viene letto l’identificatore della risorsa;
• quale identità arriva dal token o dalla sessione;
• come vengono associati utente, organizzazione, workspace e oggetto;
• se la query filtra davvero per il proprietario corretto;
• cosa succede quando l’ID viene sostituito con quello di un altro tenant;
• quali endpoint applicano una regola diversa dal resto dell’applicazione.

Il risultato che ti serve non è “sembra sicuro”. È un verdetto utilizzabile per decidere se puoi andare avanti, se devi fermare il rilascio o se devi correggere prima una superficie specifica.

Con il piano Snapshot ottieni score e valutazione generale, senza file o riga. È il punto di partenza se non sai quanto sia esposto il tuo repo. Se invece hai un SaaS già online, gestisci dati di clienti e il dubbio è tecnico — per esempio un possibile IDOR negli endpoint multi-tenant — il piano Diagnostic è quello coerente: evidenze a livello di file e riga, senza fix automatici e senza revisione umana inclusa.

L’audit non sostituisce il tuo processo di sviluppo. Riduce l’incertezza prima che quella stessa incertezza diventi un incidente, una segnalazione di un cliente o una richiesta urgente da parte di un investitore.

Cosa un linter non vede

Un linter è utile, ma risponde a domande diverse. Controlla spesso sintassi, stile, tipi, import, pattern noti e alcune categorie di errore statico. Può segnalare una variabile inutilizzata o una chiamata sospetta. Non può dare per scontato che una regola di business sia stata applicata correttamente a ogni risorsa.

Nel caso di un IDOR, il problema può essere perfettamente valido dal punto di vista del linguaggio. Questa query, per esempio, non ha nulla di sintatticamente sbagliato:

SELECT * FROM invoices WHERE id = $1;

La domanda è: perché non c’è anche il vincolo sull’account? La risposta dipende dal modello dati e dal contratto applicativo. Forse dovrebbe esserci account_id = $2. Forse la policy è applicata da Row Level Security. Forse il controllo è in un service layer. Forse manca soltanto su una rotta aggiunta ieri.

Un linter non conosce necessariamente l’intenzione di isolamento tra tenant, il significato commerciale di “fattura privata” o il fatto che un certo endpoint venga chiamato dal pannello amministrativo ma sia raggiungibile anche da un utente standard.

Neppure il test di compilazione dimostra l’autorizzazione. E una suite di test generata insieme al codice può verificare soltanto gli scenari che qualcuno ha espresso. Se lo scenario “utente A prova a leggere l’oggetto di B” non esiste, il verde dei test non è un verdetto di sicurezza.

Per questo l’audit sta nel mezzo del flusso, non alla fine come un bollino. Ti aiuta a distinguere tra codice plausibile e comportamento dimostrato. Il nemico non è aver usato Cursor. Il nemico è spedire senza sapere quale delle due cose hai davanti.

Cosa fare questa settimana

1. Elenca gli endpoint che ricevono ID di risorse: documenti, fatture, file, progetti, conversazioni, membri e pagamenti.
2. Per ciascuno, scrivi la regola di autorizzazione in una frase: “l’utente può accedere solo agli oggetti del proprio workspace”.
3. Controlla se quella regola è applicata nel punto in cui i dati vengono realmente letti o modificati, non soltanto nel frontend.
4. Cerca query che filtrano per id ma non per proprietario, tenant, workspace o relazione equivalente.
5. Aggiungi almeno un test negativo per ogni superficie sensibile: utente autenticato, ID valido, oggetto appartenente a un altro account.
6. Carica il repository su VibeInspect.ai e ottieni un verdetto prima del prossimo deploy.

Se non sai da dove partire, scegli Snapshot per capire il quadro generale. Se hai già individuato un possibile IDOR e vuoi sapere esattamente dove si trova nel codice, scegli Diagnostic.

Il tuo prodotto può essere nato in una settimana con Cursor. La decisione di mandarlo online non dovrebbe dipendere da una sensazione. Avvia l’audit del tuo repo e sostituisci il “dovrebbe andare” con un verdetto.