Cursor può rifattorizzare il codice, ma non vede chi può accedere ai dati

Un benchmark serio ricorda che il codice non è solo testo

Gli agenti di coding stanno diventando bravi a generare modifiche plausibili. Molto meno bravi, però, quando devono seguire una grande rifattorizzazione attraverso più file, linguaggi e dipendenze.

Un nuovo benchmark citato da The New Stack mette il dito proprio qui: SWE-Bench ProMax raccoglie 170 casi reali di refactoring in sette linguaggi e, secondo i dati riportati, il modello migliore ha raggiunto un resolve rate del 41,2%. Il punto non è decretare che l’AI “non sa programmare”. Il punto è più utile: un risultato buono su una modifica locale non dice quanto l’agente capisca un repository intero.

Per chi ha spedito un prodotto costruito con Cursor, questa distinzione è concreta. Il tuo progetto può compilare, i test possono passare e la UI può sembrare intatta. Eppure una modifica distribuita su route, query, componenti e servizi può avere lasciato aperto un confine che prima non esisteva.

Cosa significa se il tuo codice l’ha scritto Cursor

Prendiamo un buco tecnico preciso: l’IDOR, cioè l’accesso a una risorsa usando un identificatore valido ma senza verificare che quella risorsa appartenga davvero all’utente autenticato.

È un errore comune nei prodotti vibe-coded perché il flusso superficiale è semplice:

1. l’utente effettua il login;
2. il frontend chiama /api/invoices/123;
3. il backend cerca la fattura 123;
4. la risposta torna al browser.

La domanda decisiva è nel quarto passaggio: la fattura 123 viene restituita perché esiste, oppure perché appartiene all’utente che ha fatto la richiesta?

Durante una rifattorizzazione, Cursor può spostare una query in un repository condiviso, introdurre una nuova route o riutilizzare un endpoint già esistente. Il risultato può essere elegante e coerente dal punto di vista del codice, ma privo del controllo user_id, account_id o equivalente.

Il problema non è aver usato Cursor. Il problema è non avere un verdetto sul comportamento effettivo del repo dopo tutte quelle modifiche.

Perché ora ti serve un audit

Un audit VibeInspect serve a rispondere a una domanda che il repository, da solo, non risponde: il prodotto rispetta davvero i confini di accesso che pensi di aver implementato?

Il flusso parte dal tuo ZIP: il repo viene analizzato da specialisti AI e il risultato è un PDF con un verdetto. Non una lista infinita di suggerimenti, non una promessa generica di “best practice”, ma una lettura orientata al rischio del sistema che hai spedito.

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

• dove viene ricavato l’utente autenticato;
• quale route riceve l’identificatore della risorsa;
• quale servizio costruisce la query;
• se il filtro di proprietà viene applicato sempre o solo in alcuni percorsi;
• se esistono endpoint alternativi che restituiscono lo stesso dato;
• quali evidenze nel codice sostengono il verdetto.

Questa è la differenza tra guardare una funzione e valutare un flusso. Un controllo isolato può sembrare corretto mentre un’altra route, magari aggiunta durante una rifattorizzazione, usa lo stesso identificatore senza la verifica di appartenenza.

Per un repo costruito con Cursor, questa ricostruzione è spesso il passaggio che manca. L’agente ha prodotto il cambiamento. Il test ha confermato uno scenario. Nessuno ha però stabilito, con una valutazione indipendente, se il confine vale per tutte le varianti del percorso.

L’audit non sistema il codice e non sostituisce il tuo processo di remediation. Ti consegna però un punto di partenza leggibile: un verdetto, le evidenze disponibili e l’area da correggere prima di continuare ad aggiungere feature.

Il verdetto conta più della sensazione che “funziona”

Il rischio dei progetti vibe-coded non è soltanto il bug evidente. È l’assenza di una decisione affidabile quando il prodotto sembra pronto.

“Ho provato con il mio account e vedo solo i miei dati” non equivale a dimostrare che ogni accesso è vincolato all’identità corretta. “Cursor ha controllato la modifica” non equivale a una valutazione del comportamento complessivo. “I test passano” significa che quegli scenari passano, non che il modello di autorizzazione sia completo.

Un verdetto ti aiuta a separare tre cose che spesso vengono confuse:

• ciò che il codice dichiara di voler fare;
• ciò che i test coprono davvero;
• ciò che un utente autenticato può ottenere passando da percorsi diversi.

Questa separazione diventa ancora più importante quando una rifattorizzazione tocca molti file. Il benchmark SWE-Bench ProMax evidenzia proprio la difficoltà degli agenti nel mantenere invariato il comportamento mentre cambiano strutture ampie. Nel tuo prodotto, “invariato” non significa soltanto che il bottone continua a funzionare. Significa anche che un utente continua a vedere esclusivamente ciò che gli compete.

Il piano Snapshot può bastare se non sai ancora quanto è esposto il repo e vuoi uno score iniziale, senza dettagli su file e righe. Se invece il dubbio è tecnico e concreto — per esempio una route che potrebbe esporre dati di altri account — il piano Diagnostic è quello coerente: include file, righe ed evidenze nel PDF.

Cosa un linter non vede

Un linter può segnalare variabili inutilizzate, tipi incoerenti, import mancanti o pattern sospetti. Sono controlli utili, ma non rispondono alla domanda “l’utente A può leggere la risorsa dell’utente B?”.

Un linter vede la forma locale del codice. Un audit deve ricostruire una relazione distribuita tra identità, input, query, dati restituiti e autorizzazione.

Puoi avere codice perfettamente formattato con una query come:

SELECT * FROM invoices WHERE id = $1

La query è valida. La sintassi è corretta. L’endpoint può funzionare. Ma se manca il vincolo che lega la fattura all’account autenticato, il comportamento è sbagliato.

Anche un test generico può non bastare. Se verifica che l’utente autenticato riceva la propria fattura, ma non prova che un secondo utente venga rifiutato, lascia scoperto proprio il caso importante. E se il repository contiene più endpoint equivalenti, il test deve seguire il dato attraverso tutti quei percorsi.

Questo è il motivo per cui l’audit sta nel mezzo del processo: prima del verdetto non sai quale rischio stai davvero accettando; dopo il verdetto puoi decidere cosa correggere, cosa rimandare e cosa non portare in produzione.

Cosa fare questa settimana

Se hai spedito con Cursor, dedica un’ora a questo controllo mirato:

1. elenca le risorse sensibili: fatture, documenti, workspace, progetti, messaggi;
2. individua tutte le route che accettano un ID o uno slug di risorsa;
3. verifica dove viene applicato il controllo di proprietà;
4. prova manualmente un accesso incrociato con due account distinti;
5. controlla se frontend, API e query applicano la stessa regola;
6. congela le nuove feature finché non hai un verdetto sul rischio principale.

Non devi vergognarti del codice generato dall’AI. Devi smettere di trattarlo come se avesse già ricevuto una decisione indipendente.

Carica il repo su VibeInspect.ai e ottieni un verdetto prima del prossimo giro di modifiche. Se il problema è ancora “non so quanto rischio c’è”, parti da Snapshot. Se sospetti un IDOR o un altro buco tecnico e vuoi evidenze utilizzabili per correggere il percorso, scegli Diagnostic: avvia l’audit.