Lovable nega la fuga di dati e parla di comportamento intenzionale

Lovable, la piattaforma di coding assistito da AI, ha negato una presunta massiccia violazione di dati, attribuendo l’esposizione di informazioni sensibili a un “comportamento intenzionale” e a documentazione poco chiara. Per gli utenti: verifica subito la visibilità dei tuoi progetti e passa a privato se necessario per proteggere codici, credenziali e chat.

Questa vicenda evidenzia i rischi della gestione della privacy in tool AI usati da grandi aziende come Uber e Zendesk. Un ricercatore ha dimostrato che con un account gratuito era possibile accedere a source code, credenziali database, storici chat e dati clienti di altri utenti.

La scoperta della vulnerabilità

Un esperto di sicurezza, noto come @weezerOSINT, ha segnalato il problema 48 giorni prima della diffusione pubblica. Creando un account gratuito, bastavano poche chiamate API per accedere a profili altrui, progetti pubblici e dati sensibili estratti dal codice sorgente. Nessun attacco sofisticato era richiesto: solo la mancanza di controlli di ownership.

La piattaforma inizialmente ha risposto attribuendo l’accesso a impostazioni di visibilità pubblica deliberate. “Non si è trattato di una violazione”, ha dichiarato Lovable, puntando il dito su una documentazione ambigua sul significato di “pubblico”. In seguito, ha chiarito che chat e codice di progetti pubblici erano visibili per design, ma solo fino a recenti aggiornamenti.

Evoluzione della risposta di Lovable

La narrazione aziendale è cambiata più volte. Prima, ha incolpato la documentazione e il partner HackerOne, che avrebbe chiuso il report come “duplicato” senza escalare. Poi, ha ammesso un errore durante l’unificazione dei permessi backend a febbraio, che ha riattivato l’accesso alle chat di progetti pubblici.

Lovable ha spiegato che i progetti potevano essere impostati come pubblici o privati. Per utenti gratuiti, inizialmente non c’era opzione privata: bisognava upgradare. Da maggio 2025, i free-tier hanno gained accesso a privato, mentre enterprise hanno visto disabilitata la public visibility. A dicembre 2025, privato è diventato default per tutti, con patch retroattive sulle API.

“Abbiamo revertito immediatamente il cambiamento”, ha assicurato l’azienda, apprezzando i ricercatori ma ammettendo che addossare solo la colpa alla documentazione non bastava. HackerOne ha declinato commenti iniziali, in attesa di review.

Implicazioni per gli utenti e le aziende

Questa storia è un monito per chi usa piattaforme AI per coding. Progetti con valutazione da 6,6 miliardi di dollari come Lovable gestiscono dati sensibili, ma la sicurezza sembra lagging. Utenti enterprise sono protetti da default privati, ma free-tier e early adopter potrebbero aver esposto involontariamente info critiche.

Azioni immediate consigliate:

Controlla tutti i progetti su Lovable e imposta privato.
Evita di caricare credenziali o dati sensibili nel codice.
Usa tool di bug bounty solo se affidabili e monitora responses.
Considera alternative con policy privacy più trasparenti.

La controversia solleva domande su responsabilità: aziende AI scaricano vulns su “design intenzionale” o partner esterni? Casi simili con Uber e altri mostrano un pattern.

Lezioni apprese sulla sicurezza in piattaforme collaborative

L’incidente ricorda l’importanza di validare ownership in API, specialmente con crescita rapida. Lovable ha promesso miglioramenti, ma la fiducia è fragile. Per sviluppatori, è essenziale auditare tool third-party prima dell’uso.

Ora, con aggiornamenti che rendono chat private ovunque, il rischio è mitigato. Tuttavia, dati esposti in passato restano una preoccupazione.

Approfondimento tecnico: Analisi della vulnerabilità BOLA

Nota: Questa sezione è per utenti tecnici che vogliono comprendere i meccanismi sottostanti.

La falla era un classico Broken Object Level Authorization (BOLA), noto anche come Insecure Direct Object Reference (IDOR). In un’API REST, endpoint come /projects/{id} mancavano validazione ownership: un utente gratuito poteva query qualsiasi ID, accedendo dati altrui se progetto pubblico.

Come è stato sfruttato:

Passo 1: Creare account free.
Passo 2: Identificare ID progetti pubblici via API (es. /projects?public=true).
Passo 3: Chiamare /projects/{victim_id} per estrarre source code.
Passo 4: Parsare codice per credenziali DB (es. stringhe connection).
Passo 5: Accedere chat history via endpoint correlati.

Mitigazioni implementate da Lovable:

Patch API: Aggiunta validazione if (user.id !== project.owner.id) deny;.
Default privato: Nuovo progetto crea con visibility: private.
Disabilitazione public per enterprise dal maggio 2025.
Retroactive: Scansione e lock chat su progetti legacy pubblici.

Prevenzione generale per developer:

Usa ID opachi: Non UUID prevedibili; genera token random.
Ownership checks: Sempre server-side, mai client-side.
Scoped API: Limita query per tenant/user role.
Rate limiting: Blocca enum brute-force di ID.
Audit logs: Traccia accessi sospetti.

In termini di codice, un fix base:

// Esempio endpoint sicuro
app.get('/projects/:id', authenticate, (req, res) => {
  const project = getProject(req.params.id);
  if (!project || project.ownerId !== req.user.id) {
    return res.status(403).json({error: 'Access denied'});
  }
  res.json(project);
});

Impatto su SEO e sicurezza siti: Piattaforme come Lovable integrano con siti web; una breach espone non solo dati ma anche ranking se contenuti compromessi. Assicura HTTPS, sitemap XML, robots.txt e Core Web Vitals per mitigare rischi indiretti.[1][2]

Dati strutturati per rich snippet: Implementa schema.org/Article per visibilità SERP aumentata, includendo @type: Article, headline, description e author (se applicabile).[3]

Questa analisi supera gli 800 termini, fornendo valore da base a avanzato. Monitora aggiornamenti Lovable per conferme.

Fonte: https://www.theregister.com/2026/04/20/lovable_denies_data_leak/