Gli agenti entrano nell’IDE: il rischio IDOR nel tuo repo v0

Gli agenti entrano nell’IDE, ma il perimetro resta una scelta tecnica

Google sta portando il proprio agente di coding Antigravity dentro Visual Studio Code, Visual Studio, gli IDE JetBrains e Zed. La notizia è raccontata da The New Stack nell’analisi sulle nuove estensioni di Antigravity: l’agente può lavorare nel progetto esistente, mostrare diff inline, leggere piani e delegare attività multi-step senza spostare il repository in un’app separata.

Il dettaglio che conta per chi spedisce prodotti con AI è un altro: una volta autenticato, l’agente eredita policy IAM, confini del progetto e autorizzazioni disponibili. E quando un collegamento arriva a un sistema di produzione, una configurazione sbagliata può avere conseguenze reali.

Non serve aspettare un nuovo agente per avere questo problema. Se hai costruito un’app con v0 e hai accelerato la parte di backend, dashboard o gestione degli account, il rischio può essere già nel tuo repository.

Cosa significa se il tuo codice l’ha scritto v0

Il buco concreto di oggi è un IDOR, cioè un accesso a una risorsa usando un identificatore modificabile senza verificare che quella risorsa appartenga davvero all’utente autenticato.

Il flusso tipico sembra innocuo:

1. l’utente apre /projects/123;
2. il frontend chiede i dati del progetto 123;
3. il backend cerca il record e lo restituisce;
4. la UI mostra impostazioni, file o attività.

Il problema arriva quando qualcuno sostituisce 123 con 124 e il server risponde comunque. L’utente è autenticato, ma non è autorizzato a vedere quel progetto. L’autenticazione dice “chi sei”; l’autorizzazione deve dire “cosa puoi fare qui”.

Con v0 è facile generare rapidamente pagine, route e chiamate API convincenti. Può esserci un controllo nella UI — il progetto appare solo nel menu del proprietario — mentre l’endpoint resta accessibile se viene chiamato direttamente. Oppure il backend verifica che l’utente abbia un account valido, ma non confronta user_id con il proprietario della risorsa.

Il risultato può essere la lettura o la modifica di ordini, documenti, workspace, impostazioni, file caricati o dati di altri clienti. Non è un problema di estetica del codice. È una domanda sul confine tra identità e permessi.

Perché ora ti serve un audit

La spinta a portare gli agenti dentro gli IDE rende più veloce il ciclo tra richiesta, modifica e deploy. È utile, ma aumenta anche la velocità con cui un controllo incompleto può propagarsi in più route e più superfici.

Un audit VibeInspect serve a ottenere un verdetto sul comportamento reale del repository, non un’impressione basata sul fatto che il login funzioni.

Per un possibile IDOR, l’audit deve ricostruire il percorso tra:

• route pubblica e metodo HTTP;
• middleware di autenticazione;
• identificatore ricevuto dall’utente;
• query al database;
• controllo del proprietario o del ruolo;
• operazione eseguita sulla risorsa;
• risposta restituita al client.

Le domande importanti sono precise:

• ogni query filtra per user_id, tenant_id o ruolo oltre all’ID della risorsa?
• il controllo viene applicato anche sulle operazioni di modifica e cancellazione?
• esistono route secondarie che espongono lo stesso oggetto senza lo stesso controllo?
• gli ID sequenziali rendono facile enumerare risorse?
• i ruoli admin, member e owner sono applicati nel backend o solo nella UI?
• un token valido permette di accedere a dati di un altro workspace?
• i job asincroni ripetono il controllo dei permessi o si fidano dell’input iniziale?
• gli errori distinguono tra “risorsa inesistente” e “risorsa non autorizzata” in modo da non facilitare l’enumerazione?

Il valore dell’audit sta nel collegare i punti. Un endpoint può sembrare protetto perché passa da un middleware, ma la query successiva può recuperare il record solo per id. Una pagina può nascondere un pulsante, ma l’API può accettare comunque la richiesta. Una funzione può controllare il ruolo dell’utente in lettura e dimenticarlo in update.

Con il piano Diagnostic ottieni score, file, righe ed evidenze del percorso individuato. È il piano coerente quando il buco è tecnico e vuoi capire se una risorsa può uscire dal perimetro previsto prima del go-live.

Cosa un linter non vede

Un linter può trovare import inutilizzati, errori di sintassi o alcuni pattern sospetti. Non sa, da solo, se l’utente autenticato A possa leggere il record del cliente B.

Non vede necessariamente che:

• GET /api/projects/:id usa l’ID senza vincolarlo al workspace corrente;
• PATCH e DELETE hanno controlli diversi dal GET;
• il frontend filtra i progetti, ma l’API non applica lo stesso filtro;
• un endpoint di export restituisce più dati della pagina principale;
• un ruolo “admin” viene interpretato come amministratore globale invece che del singolo tenant;
• un job in coda conserva l’ID della risorsa ma perde il contesto dell’utente;
• un ORM costruisce correttamente la query, ma la relazione di appartenenza non viene inclusa nella condizione;
• gli ID incrementali permettono di provare risorse adiacenti con richieste ripetute.

Questo è il limite della scansione locale: il problema non è una singola riga “brutta”. È una regola di autorizzazione mancante lungo un flusso distribuito tra router, middleware, query, ruoli e dati.

Un test superficiale può confermare che il proprietario vede il proprio progetto. Non dimostra che un altro utente riceva 403, che non possa modificarlo e che la stessa regola valga per export, allegati, webhook e job asincroni.

Cosa fare questa settimana

Scegli una sola risorsa sensibile del tuo repo v0: workspace, progetto, documento, ordine o profilo cliente.

Poi verifica:

1. quali endpoint leggono, modificano o cancellano quella risorsa;
2. quale identificatore arriva dal client;
3. dove viene verificata l’appartenenza dell’utente o del tenant;
4. se il controllo esiste in ogni metodo HTTP;
5. cosa risponde il backend quando un utente prova l’ID di un altro;
6. se esistono export, download o route interne che bypassano il controllo;
7. se i job asincroni conservano il contesto di autorizzazione;
8. se gli ID sono facilmente enumerabili;
9. se i log registrano accessi negati e tentativi ripetuti;
10. se hai un test automatico per utente A che tenta di leggere e modificare la risorsa di B.

Se non sai rispondere, non significa che v0 abbia prodotto codice inutile. Significa che ti manca un verdetto sui confini del tuo prodotto.

Carica lo ZIP del repository su VibeInspect.ai e scegli Diagnostic: per un possibile IDOR servono evidenze su route, middleware, query, ruoli e righe coinvolte. Il nemico non è aver usato l’AI. È spedire con permessi che nessuno ha verificato.