La UI è pronta. Ma con v0 un altro utente può vedere i tuoi dati

Gli agenti hanno reso economiche le interfacce che prima rimandavi

La notizia di oggi parte da un’idea semplice: gli agenti di coding hanno abbassato quasi a zero il costo di trasformare un piccolo strumento in un’interfaccia nativa. Il punto non è più se puoi costruire una UI migliore, ma se hai una ragione per non farlo. È il tema di Stop Making TUIs, pubblicato da Simon Willison a partire dall’argomento di Thomas Ptacek.

Per un founder è una promessa potente: prendi una CLI, aggiungi una dashboard, rendi il flusso più accessibile e spediscilo in fretta. Ma la velocità con cui nasce l’interfaccia può nascondere un problema meno visibile: la UI mostra i dati giusti nel caso normale, però non verifica abbastanza bene quali dati l’utente ha davvero il diritto di vedere o modificare.

Cosa significa se il tuo codice l’ha scritto v0

Immagina un’app SaaS costruita con v0: ogni cliente ha progetti, documenti e fatture. L’interfaccia ha una rotta come /projects/123, recupera l’oggetto con un parametro nell’URL e lo visualizza correttamente.

Il test funzionale passa. Accedi come utente A, apri il progetto 123 e vedi il tuo contenuto. Il pulsante modifica funziona. La pagina è pulita e responsive.

Poi un utente cambia manualmente 123 in 124.

Se il backend cerca semplicemente il progetto per ID e restituisce il risultato senza verificare che appartenga all’account autenticato, l’utente A può leggere o modificare il progetto dell’utente B. Questo è un caso concreto di IDOR, cioè Insecure Direct Object Reference: l’app espone un identificatore diretto e non applica un controllo di autorizzazione sull’oggetto richiesto.

Il problema non è la presenza dell’ID nell’URL. Gli identificatori prevedibili possono essere accettabili se ogni richiesta verifica ownership o permessi. Il problema è affidarsi alla UI, a un filtro client-side o al fatto che l’utente “non dovrebbe conoscere” l’ID.

Una schermata generata da v0 può rendere il flusso convincente senza dimostrare che il confine tra account sia realmente applicato sul server. Il bottone nasconde il dettaglio. La route lo espone.

Perché ora ti serve un audit del repository

Qui il passaggio mancante non è un’altra iterazione sul design. È un verdetto sul percorso dei dati.

La domanda da fare è: ogni endpoint che riceve un identificatore controlla anche il contesto dell’utente autenticato prima di restituire o modificare l’oggetto?

Per rispondere bisogna seguire la catena completa, non fermarsi al componente visuale:

• quale pagina o chiamata API accetta l’ID;
• come viene recuperata la sessione o l’identità dell’utente;
• quale query cerca il record;
• se la query filtra anche per user_id, organization_id, tenant_id o relazione equivalente;
• se lo stesso controllo esiste su lettura, modifica, cancellazione ed export;
• se esistono endpoint alternativi che espongono lo stesso oggetto;
• se il controllo è applicato sul server oppure solo nella UI.

Un audit VibeInspect prende il repository in ZIP e restituisce un PDF con score e verdetto. Per un buco tecnico come un possibile IDOR, il piano Diagnostic è quello utile: include file, righe ed evidenze per collegare route, autenticazione, query e autorizzazione.

Il risultato che ti serve non è “la pagina sembra protetta”. È una conclusione operativa: PASS, oppure FAIL, con la spiegazione del percorso che consente a un utente autenticato di attraversare il confine del proprio account.

Questo conta ancora di più quando il progetto è nato da prompt rapidi. Non devi dimostrare che v0 abbia scritto codice irresponsabile. Devi dimostrare che il repository applica davvero le regole di accesso che il prodotto promette.

L’evidenza deve seguire l’oggetto, non solo il pulsante

Un falso positivo è facile. Trovare projectId in una route non dimostra da solo una vulnerabilità. Potrebbe esistere un middleware globale, una policy nell’ORM o un controllo in un service condiviso.

Allo stesso modo, vedere una funzione chiamata authorizeProject non basta. Bisogna verificare che venga usata in ogni percorso rilevante e che controlli la relazione corretta. Un’app multi-tenant può avere un controllo sugli endpoint di lettura e dimenticarlo su /export, /duplicate o /api/projects/:id/settings.

Il report deve quindi distinguere tra:

1. identificatore esposto ma protetto da una verifica server-side coerente;
2. controllo presente in un solo percorso, con endpoint paralleli non protetti;
3. recupero diretto dell’oggetto senza vincolo sul tenant o sull’utente.

Il valore dell’audit è ricostruire questa differenza e trasformarla in evidenza. Non serve un commento generico sul fatto che “gli ID sequenziali sono rischiosi”. Serve mostrare dove l’oggetto viene cercato e quale condizione impedisce, oppure non impedisce, l’accesso cross-account.

Cosa un linter non vede

Un linter controlla regole locali: sintassi, tipi, import, formattazione e alcuni pattern noti. Non sa necessariamente che il record project appartiene a un’organizzazione diversa da quella della sessione corrente.

Non conosce sempre il significato di una relazione tra tabelle. Non ricostruisce da solo che una pagina usa un endpoint pubblico diverso da quello testato. Non può stabilire se un controllo client-side viene aggirato chiamando direttamente l’API.

Anche i test possono dare un falso senso di sicurezza. Se la suite crea un solo account e un solo progetto, l’applicazione funziona. Se verifica soltanto che l’utente autenticato riceva una risposta 200, non sta dimostrando che un secondo account riceva 403 sullo stesso oggetto.

Il linter dice che il codice rispetta certe regole. L’audit ti dice se il repository applica il confine di autorizzazione lungo il flusso reale. Sono due domande diverse.

La stessa distinzione vale per l’interfaccia nativa. Una UI più elegante può ridurre attrito e aumentare l’uso del prodotto, ma non sostituisce il controllo server-side. Se l’agente ha reso economico spedire la schermata, devi rendere altrettanto economico verificare cosa può attraversare.

Cosa fare questa settimana

1. Scegli una risorsa sensibile: progetto, documento, fattura, ticket o workspace.
2. Elenca tutte le route e gli endpoint che ricevono il suo identificatore.
3. Verifica che ogni query applichi anche il vincolo di account, tenant o ownership.
4. Ripeti il controllo su lettura, modifica, cancellazione, duplicazione ed export.
5. Aggiungi un test con due utenti appartenenti a organizzazioni diverse.
6. Controlla che il rifiuto avvenga sul server e non solo nascondendo il pulsante nella UI.
7. Se hai usato v0 per costruire o rifare il flusso e non sai formulare un verdetto, esegui un audit Diagnostic prima del prossimo rilascio.

Non devi rallentare perché hai usato l’AI. Devi smettere di confondere una UI convincente con un confine verificato. La notizia dice che oggi puoi costruire interfacce migliori molto più rapidamente. La conseguenza pratica è che il controllo di accesso deve entrare nello stesso ciclo, prima che quella UI diventi il modo più semplice per raggiungere l’oggetto sbagliato.

Carica lo ZIP del repository e ottieni un verdetto con evidenze tecniche: avvia un audit Diagnostic.