Il filtro non basta: se Lovable può uscire dal tuo perimetro

Un modello può trasformare dati apparentemente innocui in un’azione

Una ricerca di Adversa ha mostrato un problema concreto nei sistemi AI con strumenti: un payload malevolo inserito in una pagina web veniva rifiutato quando era scritto in chiaro, ma riusciva a passare quando era cifrato con AES-256-GCM. Il modello decifrava il contenuto nel proprio ambiente di esecuzione e poi seguiva le istruzioni, fino a inviare dati di sessione verso un URL controllato dall’attaccante.

La notizia è riportata da The New Stack nell’analisi sull’attacco tramite prompt injection cifrata. Il punto da portare nel tuo repository non è che ogni app AI sia già compromessa. È più semplice e più scomodo: un controllo sul testo in ingresso non basta se il sistema può trasformare quel testo, usarlo come istruzione e poi chiamare servizi esterni.

Cosa significa se il tuo codice l’ha scritto Lovable

Se hai usato Lovable per costruire una web app che importa URL, documenti, immagini, feed o contenuti da API esterne, probabilmente hai già un punto sensibile: il server riceve un indirizzo e prova a raggiungerlo per conto dell’utente.

Il buco concreto è una SSRF, Server-Side Request Forgery: un endpoint controllato dall’utente può indurre il backend a effettuare richieste verso destinazioni che non dovrebbe raggiungere.

Il caso tipico è un campo come url, webhook_url, image_url o document_url. Nel percorso felice funziona così:

1. l’utente incolla un indirizzo;
2. il backend lo scarica;
3. l’app analizza il contenuto;
4. restituisce un risultato.

Ma cosa succede se l’indirizzo punta a localhost, a una rete privata, al pannello di metadati del cloud o a un servizio interno? E se il server segue redirect? E se la risposta contiene istruzioni che un agente o un workflow interpreta come attendibili?

Lovable può accelerare moltissimo la costruzione dell’interfaccia e del flusso applicativo. Il problema non è averlo usato. Il problema è spedire senza sapere quale perimetro abbia davvero il backend.

Perché ora ti serve un audit

Un audit VibeInspect serve a trasformare questa domanda vaga — “il mio endpoint è sicuro?” — in un verdetto basato sul repository.

Per una possibile SSRF, l’audit deve ricostruire il percorso completo, non limitarsi a cercare una stringa sospetta. Deve verificare almeno:

• quali endpoint accettano URL o destinazioni controllate dall’utente;
• se vengono consentiti schemi oltre a https;
• se l’app risolve DNS prima della connessione e ricontrolla l’indirizzo dopo la risoluzione;
• se blocca loopback, reti private, indirizzi link-local e metadati cloud;
• se segue redirect verso destinazioni non consentite;
• se applica timeout, limiti di dimensione e limiti di risposta;
• se il client HTTP può raggiungere la rete interna dal runtime di produzione;
• se gli header di autenticazione vengono inoltrati a destinazioni non fidate;
• se il contenuto scaricato viene passato a un agente, a un parser o a un esecutore di codice;
• se esistono log sufficienti per capire chi ha richiesto cosa e dove.

Queste verifiche contano perché il rischio raramente vive in una sola riga. Può nascere dalla combinazione tra validazione incompleta, libreria HTTP configurata con valori predefiniti, redirect automatici e un servizio deployato in una rete più privilegiata di quanto l’applicazione richieda.

Il risultato utile non è una lista di consigli generici. È sapere se il repository contiene un percorso sfruttabile, quali componenti lo rendono possibile e quali evidenze lo dimostrano. Per questo, quando il buco è tecnico e il prodotto deve andare online, il piano Diagnostic è quello coerente: score, file, righe ed evidenze.

Cosa un linter non vede

Un linter può segnalare una variabile non usata, una dipendenza obsoleta o alcuni pattern pericolosi. Non può ricostruire da solo il confine di rete del tuo deployment.

Non vede necessariamente che:

• la validazione controlla il testo dell’URL ma non l’indirizzo IP finale;
• il parser accetta http, file, ftp o schemi inattesi;
• il client segue tre redirect e l’ultimo porta a una rete privata;
• il controllo DNS viene fatto una volta, ma la connessione usa una risoluzione diversa;
• un proxy interno aggiunge credenziali a ogni richiesta in uscita;
• il corpo della risposta viene consegnato a un agente senza separare dati e istruzioni;
• l’endpoint è protetto dall’autenticazione, ma può essere chiamato da un’integrazione con permessi troppo ampi;
• il rate limit è applicato alla UI e non al backend;
• un errore di rete viene ritentato senza un tetto, amplificando il traffico verso la destinazione.

Il linter guarda soprattutto il codice in isolamento. Una SSRF è un difetto di confine: riguarda input, risoluzione DNS, rete, proxy, credenziali, redirect e comportamento del servizio quando riceve contenuto non fidato.

Anche uno scanner automatico può fermarsi troppo presto. Può vedere una funzione chiamata fetchUrl() e non sapere che quella funzione viene invocata da un job asincrono, con accesso alla VPC e a un token di servizio. Serve un audit che legga il flusso end-to-end e produca un verdetto.

Cosa fare questa settimana

Scegli un solo flusso del tuo repo Lovable che scarica o invia dati verso un indirizzo fornito dall’utente. Non partire da tutta l’app: parti dal punto in cui il server esce verso la rete.

Poi verifica:

1. quali schemi URL sono ammessi;
2. quali IP vengono risolti prima della connessione;
3. se loopback, reti private e link-local sono bloccati;
4. se i redirect vengono disabilitati o ricontrollati a ogni passaggio;
5. quali timeout e limiti di risposta sono configurati;
6. quali credenziali o header vengono inoltrati;
7. se il servizio ha accesso alla rete interna senza averne bisogno;
8. se il contenuto recuperato viene trattato solo come dati;
9. se esistono log e alert per richieste anomale;
10. cosa succede con URL duplicati, non raggiungibili o molto lenti.

Se non sai rispondere, non significa che Lovable abbia scritto codice inutilizzabile. Significa che ti manca un verdetto sul perimetro reale della tua app.

Carica lo ZIP del repository su VibeInspect.ai e scegli Diagnostic: per una SSRF servono evidenze tecniche su file, righe, chiamate HTTP, validazioni e configurazione di rete. Il nemico non è l’AI che ti ha aiutato a spedire. È spedire senza sapere dove il tuo server può arrivare.