Il tuo repo Cursor funziona: ma chi può leggere i dati degli altri?

Il codice passa i test, ma il verdetto ancora non c’è

La notizia di oggi parte da una distinzione semplice e importante: verificare una modifica non significa soltanto leggere ogni riga di codice. In un progetto costruito con agenti, bisogna anche dimostrare che il cambiamento è stato applicato nel modo corretto e che il comportamento risultante è quello atteso. È il punto centrale di More than just code review, pubblicato il 22 agosto 2026.

Per chi ha spedito un prodotto costruito con Cursor, questa distinzione è concreta. Il repository può compilare. I test possono essere verdi. Il flusso principale può sembrare perfetto. Eppure un utente potrebbe riuscire a leggere o modificare la risorsa di un altro semplicemente cambiando un identificativo nella richiesta.

Il buco che scegliamo oggi è l’IDOR: Insecure Direct Object Reference. In italiano: un riferimento diretto a un oggetto senza un controllo robusto sul fatto che l’utente abbia davvero il diritto di accedervi.

Cosa significa se il tuo codice l’ha scritto Cursor

Immagina una dashboard SaaS con URL o endpoint di questo tipo:

GET /api/invoices/1842

Cursor può aiutarti a costruire rapidamente il modello Invoice, la pagina di dettaglio e l’endpoint API. Può anche aggiungere il controllo che l’utente sia autenticato. Il problema nasce quando autenticazione e autorizzazione vengono trattate come la stessa cosa.

Essere autenticati significa soltanto: “so chi sei”. Essere autorizzati significa: “puoi vedere proprio questa fattura?”.

In un’implementazione fragile, il server verifica che esista una sessione valida e poi cerca la fattura usando l’ID ricevuto dal client. Se non aggiunge anche il vincolo sul proprietario, sull’organizzazione o sulla relazione corretta, l’utente A può provare /api/invoices/1843 e ricevere la fattura dell’utente B.

È un errore tipico dei repo vibe-coded perché il percorso felice è facile da dimostrare: accedi, apri la tua fattura, visualizzi i dati. Il percorso che manca è quello avverso: accedi come utente diverso, sostituisci l’ID, ripeti la richiesta e controlli se il server risponde comunque.

Cursor non è il nemico. Il problema è che un agente può produrre molto velocemente una superficie applicativa più grande della tua capacità di verificare ogni relazione tra identità, tenant e risorsa.

Perché ora ti serve un audit: non basta sapere che “funziona”

Un audit tecnico serve a trasformare un’impressione in un verdetto sul repository che stai davvero per mettere online.

Nel caso dell’IDOR, il punto non è cercare una stringa sospetta o un pattern noto. Bisogna ricostruire il percorso completo della risorsa:

• da dove arriva l’identificativo;
• chi può modificarlo o controllarlo;
• quale middleware verifica la sessione;
• dove viene applicato il filtro su utente, team o organizzazione;
• quali endpoint leggono, aggiornano o cancellano la stessa risorsa;
• se il controllo è presente anche nei percorsi meno visibili, come export, download, webhook o job asincroni.

Un audit deve quindi arrivare a una risposta operativa: l’accesso è vincolato al soggetto corretto oppure no? Se c’è una violazione, quali file e quali punti del flusso la rendono possibile? Quale evidenza collega il verdetto al comportamento osservato?

Questo è il passaggio che spesso manca dopo una sessione con Cursor. Hai una demo, magari anche una suite di test, ma non hai ancora una valutazione indipendente della superficie di rischio. Il problema non è la velocità con cui hai scritto il codice. È l’assenza di una risposta verificabile alla domanda: “chi può fare cosa, su quale dato, in quale condizione?”.

Per un buco di autorizzazione, il piano adatto è Diagnostic: restituisce score, file, righe ed evidenze tecniche. Non applica fix e non sostituisce una revisione umana. Ti dà però una base precisa per decidere cosa correggere prima del go-live.

Il processo parte dal tuo ZIP repository, analizza il progetto con specialisti AI e produce un PDF con il verdetto. Non devi configurare un server dedicato e il sorgente viene cancellato a fine analisi.

Cosa un linter non vede

Un linter è utile, ma non può rispondere da solo alla domanda di autorizzazione.

Può segnalare variabili non usate, import inutilizzati, problemi di stile, tipi incoerenti o alcuni pattern pericolosi. Può aiutarti a mantenere il codice leggibile e a intercettare errori locali.

L’IDOR, invece, è spesso un errore di relazione e di contesto. La query può essere perfettamente valida. Il tipo può essere corretto. L’endpoint può restituire una risposta con schema impeccabile. Il difetto sta nel fatto che il record selezionato non è legato al chiamante nel modo giusto.

Un linter non sa necessariamente che invoice_id=1842 appartiene a un altro account. Non conosce sempre la regola di business secondo cui un amministratore di un workspace può leggere le fatture del proprio workspace, ma non quelle di un altro tenant. Non può inferire con affidabilità che un download generato da un job debba mantenere la stessa autorizzazione della richiesta originale.

Nemmeno una scansione superficiale dei segreti risolve il problema. Qui non manca una singola riga “sospetta”: manca una prova che il controllo di accesso sia coerente in tutti i percorsi che toccano la risorsa.

I test automatici aiutano, ma solo se includono scenari negativi espliciti. Un test che verifica che Mario possa leggere la fattura 1842 non dimostra che Luca non possa leggerla. La differenza tra le due asserzioni è esattamente il confine dell’autorizzazione.

Cosa fare questa settimana

Se hai spedito con Cursor, non ricominciare dal codice. Parti dal comportamento che vuoi garantire.

1. Elenca le risorse sensibili: fatture, documenti, ticket, report, file caricati, profili e dati di pagamento.
2. Per ogni risorsa, scrivi chi può leggerla, modificarla, eliminarla o esportarla.
3. Cerca tutti gli endpoint che accettano ID, slug, UUID o URL firmati dal client.
4. Prova ogni flusso con due utenti appartenenti a organizzazioni diverse.
5. Ripeti i test su lettura, modifica, cancellazione, download ed export.
6. Controlla che webhook, code e job asincroni non perdano il contesto dell’utente o del tenant.
7. Conserva le evidenze: richiesta, identità usata, risposta ricevuta e regola che avrebbe dovuto bloccarla.

Poi chiediti se hai un risultato o soltanto una sensazione. “Sembra isolato” non è un verdetto. “L’utente B non può leggere la fattura dell’utente A nell’endpoint X, mentre l’endpoint Y non applica il filtro tenant” è un verdetto utilizzabile.

Se non sai ancora quanto è esposto il tuo repo, parti da VibeInspect.ai con Snapshot. Se invece il sospetto è già tecnico — come un possibile IDOR, un controllo RLS mancante o una regola di autorizzazione incoerente — scegli Diagnostic e ottieni evidenze a livello di file e riga.

Il codice generato da Cursor può essere un ottimo acceleratore. Ma prima di affidargli dati reali, serve qualcosa di più di una demo riuscita: un audit che dica dove sei, cosa hai spedito e quale rischio devi correggere adesso.