Il tuo repo Cursor sa chi può fare cosa?

Gli agenti stanno diventando colleghi, ma i permessi restano codice

Una nuova generazione di agenti AI sta introducendo profili persistenti, memoria, ruoli e accessi che sopravvivono alle singole conversazioni. È il punto centrale di Grok, Claude e Hermes introducono identità persistenti per gli agenti: dietro un nome e un avatar non c’è necessariamente un “collega”, ma una configurazione che può conservare credenziali, stato e autorizzazioni.

Per chi ha spedito un prodotto costruito con Cursor, il problema è molto concreto. L’interfaccia può sembrare corretta, i test possono passare e il login può funzionare. Ma basta che un endpoint verifichi che l’utente sia autenticato, senza verificare che abbia il diritto di leggere o modificare quella specifica risorsa, per aprire un IDOR.

IDOR significa Insecure Direct Object Reference: un utente cambia un identificatore nella richiesta e accede all’oggetto di un altro utente. Per esempio: /api/projects/123 diventa /api/projects/124, e il server restituisce comunque i dati.

Cosa significa se il tuo codice l’ha scritto Cursor

Cursor è bravo a trasformare una richiesta in una feature completa: schema dati, pagina, API route, query e gestione dello stato. Il rischio nasce quando il requisito importante non è scritto nella UI, ma nella relazione tra utenti, organizzazioni e risorse.

“Mostra la dashboard del progetto” sembra una richiesta semplice. In produzione dovrebbe significare almeno questo:

• l’utente è autenticato;
• appartiene all’organizzazione corretta;
• il progetto appartiene a quell’organizzazione;
• il ruolo dell’utente permette quell’azione;
• ogni query applica questi vincoli, non solo la pagina che chiama l’API.

Un agente può implementare il percorso felice senza collegare davvero tutte queste relazioni. Può usare un projectId ricevuto dal client e fidarsi del valore. Può controllare il ruolo in una route ma dimenticarlo in una seconda route. Può proteggere la lettura e lasciare scoperta la modifica. Può applicare una policy nella UI, dove non è una barriera di sicurezza.

Questo non significa che Cursor sia “sbagliato”. Significa che il repo ora contiene decisioni di autorizzazione che qualcuno deve verificare con un verdetto.

Perché ora ti serve un audit

Quando il problema è tecnico, non basta sapere che “c’è autenticazione”. Devi sapere se il confine tra un utente e i dati di un altro viene rispettato in ogni percorso rilevante.

Un audit VibeInspect parte dal repository ZIP e ricostruisce il comportamento dello stack: modelli, middleware, route, query, policy e punti in cui l’identità dell’utente dovrebbe essere collegata alla risorsa richiesta. L’obiettivo non è produrre una lista generica di buone pratiche, ma arrivare a una conclusione operativa: il repo presenta un rischio di accesso tra tenant o utenti? Dove si manifesta? Quale evidenza lo dimostra?

Nel caso di un possibile IDOR, il valore dell’audit sta nel collegare tre elementi:

1. L’input controllabile dall’utente, come un ID nel path, nel body o nei parametri.
2. Il percorso applicativo, cioè la route e la funzione che trasformano quell’input in una query o in un’azione.
3. Il controllo mancante o insufficiente, per esempio una query filtrata solo per id invece che per id e organization_id.

Il risultato deve distinguere un sospetto da un problema dimostrato. Un riferimento a una stringa projectId non è automaticamente una vulnerabilità. Lo diventa quando il codice consente di usarla per raggiungere una risorsa fuori dal perimetro autorizzato.

Per questo il piano adatto, se hai già utenti reali o dati sensibili, è il Diagnostic: score, file, riga ed evidenze, senza fix automatici e senza revisione umana fuori dal piano Assurance. Ti serve capire cosa bloccare prima del go-live, non ricevere un altro elenco di consigli astratti.

Cosa un linter non vede

Un linter può segnalare una variabile inutilizzata, un pattern rischioso o un errore di stile. Gli strumenti SAST possono riconoscere alcune forme note di input non validato. Ma un linter non conosce necessariamente la regola di business secondo cui:

• Alice può vedere il progetto 123;
• Bob può vedere il progetto 124;
• entrambi appartengono alla stessa piattaforma, ma a organizzazioni diverse;
• un amministratore può modificare, mentre un membro può solo leggere.

Queste sono relazioni tra identità e oggetti. Non sono sempre esprimibili come una regola sintattica locale.

Lo stesso vale per i casi più subdoli: un endpoint di export che usa una query diversa dalla dashboard, una funzione server-side che salta il middleware, una mutazione GraphQL con un resolver meno protetto, oppure una policy RLS applicata a una tabella ma non a una vista o a una funzione SQL.

Il codice può compilare. Il test dell’utente proprietario può passare. La schermata può funzionare perfettamente. Eppure un secondo utente può ricevere dati che non dovrebbe vedere.

L’audit serve proprio a trasformare questa incertezza in un verdetto leggibile: passa, non passa, oppure serve ulteriore evidenza. Il nemico non è aver usato l’AI. È spedire senza sapere quale dei tre casi descrive il tuo repo.

Cosa fare questa settimana

Prendi il repository che oggi gestisce autenticazione, progetti, documenti, fatture o dati cliente e fai un inventario rapido:

1. Elenca tutte le risorse che appartengono a un utente, team o organizzazione.
2. Elenca tutte le route che leggono, modificano, eliminano o esportano quelle risorse.
3. Per ogni route, annota da dove arriva l’identificatore della risorsa.
4. Cerca query filtrate solo per id, senza un vincolo sull’identità o sul tenant.
5. Verifica che i controlli siano applicati lato server, non soltanto nella UI.
6. Controlla i percorsi meno visibili: export, download, webhook, job asincroni e API interne.
7. Conserva il commit esatto che vuoi mandare in produzione.

Se non riesci a spiegare in una frase perché ogni route può raggiungere quella risorsa, non hai ancora un verdetto.

Carica lo ZIP del repo su VibeInspect.ai e scegli Diagnostic. Ricevi evidenze tecniche su file e righe, senza server permanente: il sorgente viene cancellato a fine analisi. Non è un pentest e non sistema il codice. È il passaggio che manca tra “Cursor ha generato una feature” e “so cosa sto spedendo”.

FAQ

Un IDOR può esistere anche se uso Supabase o un ORM?

Sì. Supabase, RLS e ORM riducono il lavoro manuale, ma una policy assente, incompleta o aggirata da una funzione server-side può lasciare il controllo scoperto.

Cursor può rilevare da solo un problema di autorizzazione?

Può aiutarti a cercarlo, ma non dovresti trattare la sua spiegazione come un verdetto. Serve analizzare il percorso completo tra identità, risorsa, query e policy.

Basta controllare che l’utente sia loggato?

No. L’autenticazione dice chi è l’utente. L’autorizzazione decide cosa può fare e su quale oggetto. Un IDOR nasce spesso proprio dalla confusione tra questi due livelli.

Quale piano VibeInspect devo scegliere?

Se vuoi solo uno score iniziale, scegli Snapshot. Se stai indagando un possibile IDOR o un altro buco tecnico e ti servono file, righe ed evidenze, scegli Diagnostic.

L’audit corregge il codice?

No. VibeInspect produce un verdetto e le evidenze disponibili nel repo. La correzione resta al tuo team.