Mythos 5 entra negli scanner: il tuo repo Lovable ha un verdetto?

La sicurezza non si misura più solo dal codice che compila

Anthropic ha portato il modello Mythos 5 dentro Claude Security, il suo strumento per analizzare repository e individuare vulnerabilità. La scelta è significativa: il modello, considerato troppo rischioso per un accesso diretto e generalista, viene invece usato per produrre risultati difensivi specifici, come alert e patch. La notizia completa è Anthropic brings Mythos 5 to its Claude Security vulnerability scanner.

Il messaggio per chi costruisce prodotti con l’AI è semplice: la capacità di generare codice cresce più velocemente della capacità di dimostrare che quel codice sia pronto. Non basta più dire “l’app funziona”. Devi sapere cosa può fare un utente autenticato quando cambia un identificatore nella URL, nel body o in una chiamata API.

Questo è il caso concreto che prendiamo oggi: IDOR, cioè accesso a una risorsa di un altro utente modificando un riferimento che il server accetta senza verificare davvero la proprietà.

Cosa significa se il tuo codice l’ha scritto Lovable

Con Lovable puoi arrivare rapidamente a un’app con autenticazione, dashboard, profili, documenti, ordini o dati organizzati per account. Il flusso visibile sembra corretto: l’utente accede, vede la propria pagina e interagisce con i propri record.

Il problema può essere nascosto un livello sotto.

Immagina un endpoint come /api/invoices/123 o una query che riceve user_id dal client. La schermata mostra il documento corretto per l’utente loggato, ma il backend si limita a cercare il record con quell’ID. Se l’utente sostituisce 123 con 124 e il server restituisce il documento di un altro account, hai un IDOR.

Non serve un attacco sofisticato. Serve una richiesta valida, fatta con un account valido, verso una risorsa che non dovrebbe essere visibile.

In un repo vibe-coded questo rischio può comparire in più forme:

• un controllo del proprietario presente nella UI ma assente nell’endpoint;
• una query filtrata per id, ma non per owner_id o organization_id;
• una policy RLS applicata solo ad alcune tabelle;
• un’azione di aggiornamento che verifica la lettura ma non la modifica;
• un identificatore prevedibile usato per file, ordini, ticket o workspace;
• una funzione server che si fida di un user_id inviato dal browser.

Lovable può collegare velocemente interfaccia, autenticazione e database. Ma la velocità del builder non produce automaticamente un verdetto sul confine tra “dati dell’utente” e “dati di chiunque conosca un ID”. Quel confine va verificato nel percorso reale della richiesta.

Perché ora ti serve un audit: il verdetto che manca

La novità su Mythos 5 mette a fuoco una distinzione importante: non conta solo quanto è potente lo strumento che analizza il codice, conta anche come viene incanalato il suo output. Un sistema che restituisce un alert o una patch controllata è diverso da un modello a cui consegni accesso operativo senza limiti.

Per il tuo repo Lovable, l’audit serve a rispondere a una domanda altrettanto precisa:

un utente autenticato può leggere o modificare dati appartenenti a un altro utente, team o workspace cambiando un identificatore controllabile dal client?

Per rispondere non basta cercare una parola come authorization. Devi ricostruire il flusso completo:

1. come viene identificato l’utente autenticato;
2. quale valore arriva dal browser o dall’app;
3. quale endpoint o server action lo riceve;
4. quale query viene eseguita sul database;
5. quali policy o controlli applicano il vincolo di proprietà;
6. cosa succede se l’identificatore appartiene a un altro account;
7. se la stessa protezione esiste anche nei percorsi di modifica e cancellazione.

Questo è il tipo di analisi che trasforma il sospetto in un risultato utilizzabile. Il verdetto non è “il codice sembra sicuro”. È qualcosa di più operativo: nessuna evidenza di accesso cross-tenant nel percorso analizzato, oppure controllo mancante in uno specifico flusso, con il punto da esaminare e la conseguenza potenziale.

VibeInspect prende il repository ZIP, lo analizza con specialisti AI e restituisce un PDF con score e verdetto. Nel piano Diagnostic il report include evidenze riferite a file e righe. Non modifica il codice, non è un pentest e non promette che ogni rischio del prodotto sia escluso. Ti dà però la risposta che manca prima del go-live: dove il controllo esiste, dove non è dimostrato e quale percorso merita attenzione.

Le evidenze che distinguono un IDOR reale da un falso allarme

Un audit utile non si ferma alla presenza di autenticazione. L’autenticazione dice chi sei. L’autorizzazione dice cosa puoi fare con quella specifica risorsa.

Nel repo, le evidenze più importanti sono le combinazioni:

• Query per identificatore senza vincolo di account. Una ricerca come where id = inputId è sospetta se non è accompagnata da un filtro sulla proprietà o sul workspace.
• ID preso dal client e riutilizzato come identità. Il server dovrebbe ricavare l’utente dalla sessione verificata, non fidarsi di user_id inviato dal browser.
• Controllo solo nella pagina. Nascondere un pulsante o impedire una navigazione nel frontend non protegge l’endpoint.
• RLS incompleta o incoerente. Una tabella può essere protetta mentre una vista, una funzione SQL o un percorso amministrativo espone gli stessi dati senza il medesimo vincolo.
• Mutazioni meno protette delle letture. Un utente potrebbe non riuscire a leggere il record altrui, ma riuscire comunque a modificarlo o cancellarlo se l’operazione usa un controllo diverso.
• Risorse secondarie non coperte. Allegati, URL firmati, esportazioni e download possono avere autorizzazioni separate dalla schermata principale.

Il punto non è accumulare avvisi. È stabilire se una risorsa ha un proprietario verificato in ogni operazione sensibile.

Cosa un linter non vede

Un linter può segnalare una variabile non usata, un tipo incoerente, una promessa non gestita o una regola di formattazione violata. Può anche individuare alcuni pattern sospetti. Ma non conosce necessariamente la relazione di autorizzazione tra un utente, un’organizzazione e una riga del database.

Non vede, da solo, che:

• la UI mostra solo i record corretti, mentre l’API restituisce qualunque ID valido;
• una policy RLS copre select ma non update o delete;
• una server action usa un parametro ricevuto dal client invece dell’identità della sessione;
• un file viene protetto in fase di creazione ma pubblicato tramite un URL riutilizzabile;
• due endpoint applicano regole diverse alla stessa risorsa;
• il percorso di invito o cambio workspace consente di attraversare il confine tra tenant.

Nemmeno i test del caso nominale bastano. Un test può confermare che Alice vede il proprio ordine. La domanda dell’audit è diversa: cosa vede Alice se chiede esplicitamente l’ordine di Bob? E cosa succede se prova a modificarlo?

Il linter controlla la forma locale. L’audit ricostruisce il comportamento tra identità, input, query e dati.

Cosa fare questa settimana

Scegli una sola risorsa sensibile: fatture, documenti, ticket, profili, ordini o workspace. Non partire da tutto il prodotto.

Poi prepara una piccola matrice con quattro colonne:

• ruolo o tipo di utente;
• risorsa richiesta;
• operazione, tra lettura, modifica, eliminazione o download;
• controllo che dimostra la proprietà della risorsa.

Cerca soprattutto i punti in cui un ID arriva dal client. Verifica che il backend ricavi l’identità dalla sessione, che la query filtri anche per account o organizzazione e che le policy del database coprano tutte le operazioni, non solo la lettura.

Se non sai indicare il file, la funzione e la regola che impediscono l’accesso cross-tenant, non aggiungere ancora un’altra feature generata dall’AI. Ti serve prima un verdetto sul repo.

Carica lo ZIP su VibeInspect.ai. Per un possibile IDOR sceglierei il piano Diagnostic, perché il problema è tecnico e hai bisogno di evidenze su file, righe e percorso di autorizzazione.

L’obiettivo non è dimostrare che Lovable abbia scritto codice “sbagliato”. È sapere se il tuo prodotto separa davvero i dati degli utenti quando qualcuno prova a uscire dal percorso previsto.