La violazione dei dati di Moltbook: quando il vibe coding diventa un incubo per la sicurezza
Sicurezza

La violazione dei dati di Moltbook: quando il vibe coding diventa un incubo per la sicurezza

La violazione di Moltbook ha esposto 1,5 milioni di chiavi API dopo che una piattaforma vibe-coded ha hardcodato le credenziali Supabase nel JavaScript lato client. Ecco cosa è andato storto, perché conta e come proteggere il tuo codice generato da AI.

Di GetFree Team·19 febbraio 2026·5 min di lettura

La violazione dei dati di Moltbook: quando il vibe coding diventa un incubo per la sicurezza

What Actually Happened at Moltbook?

Lascia che ti spieghi esattamente cosa è andato storto, perché i dettagli contano.

Moltbook è stato costruito usando Supabase — una popolare alternativa open-source a Firebase che fornisce database PostgreSQL ospitati. Supabase è diventato il backend di scelta per le app sviluppate con vibe coding perché gestisce autenticazione, database e archiviazione con una configurazione minima.

Il problema? Qualcuno (o qualche IA) ha messo una chiave API di Supabase direttamente nel codice JavaScript lato client. Questo è un errore di sicurezza fondamentale. Le chiavi API appartengono al server, mai nel codice che gira nel browser dell'utente.

Ma la situazione peggiora.

Quella chiave API aveva pieno accesso in lettura e scrittura all'intero database. E Moltbook non aveva abilitato la Sicurezza a Livello di Riga (RLS) — una funzionalità di Supabase che controlla chi può accedere a quali dati. La RLS è opzionale quasi quanto la cintura di sicurezza. Potresti pensare di non averne bisogno finché non ti schianti.

I ricercatori di sicurezza di Wiz hanno trovato la chiave esposta entro pochi minuti dall'osservazione del sito web. Avrebbero potuto:

  • Scaricati tutti i 1,5 milioni di chiavi API (inclusi chiavi per OpenAI, Anthropic e altri provider AI)
  • Messaggi privati accessati tra agenti AI
  • Modificato o eliminato qualsiasi dato nel database
  • Hijacked qualsiasi account utente
  • Sostieni bollette enormi utilizzando API rubate

Il colpo di scena? Il fondatore ha ammesso di aver "completamente fatto vibe coding" l'intera piattaforma. Nessun codice review. Nessun audit di sicurezza. Solo prompt a un'IA e copia-incolla dei risultati.

Perché Questo Continua ad Accadere

Ecco cosa è frustrante di questa storia: non è unica.

Ricorda quando DeepSeek ha esposto le sue chiavi API? O Base44? Il pattern si ripete perché la filosofia del vibe coding scoraggia attivamente le pratiche che prevengono queste violazioni.

La filosofia di base del vibe coding è: muoviti velocemente, concentrati sui risultati, non preoccuparti dei dettagli. È seducente perché — onestamente — funziona per costruire prototipi. Puoi creare un'app funzionante in poche ore.

Ma le applicazioni di produzione vivono in un mondo diverso. Gestiscono dati utente reali, pagamenti reali, minacce di sicurezza reali. La stessa mentalità che ti aiuta a rilasciare un prototipo in un weekend farà hackerare la tua app di produzione al primo giorno.

Ho parlato con un ricercatore di sicurezza specializzato in codice generato da AI. Ecco cosa lo tiene sveglio di notte:

  • Non capisce cosa sta succedendo: Quando dai un prompt all'IA per "creare un sistema di accesso", ottieni codice che sembra un sistema di accesso ma potrebbe avere difetti sottili che solo un esperto noterebbe
  • Fidarsi dell'AI: Gli utenti presumono che il codice generato dall'AI sia sicuro perché... è dall'AI? Quella supposizione è completamente sbagliata
  • Fondamentali Mancanti: I vibe coder spesso non sanno cosa non sanno sulla sicurezza

Il Problema del 45%

Fammi dare un numero che dovrebbe tenerti sveglio di notte: 45%.

Quella è la percentuale di codice generato da AI che contiene vulnerabilità di sicurezza, secondo la ricerca di Veracode sul software generato da AI[1].

Non si tratta di modelli AI scadenti o sviluppatori incompetenti. Si tratta della natura fondamentale della generazione di codice. I modelli AI sono addestrati su codice esistente — che include codice insicuro. Riproducono schemi che hanno visto, inclusi quelli vulnerabili.

Vulnerabilità comuni nel codice generato dall'AI includono:

VulnerabilitàCosa SignificaImpatto nel mondo reale
SQL InjectionGli attaccanti possono eseguire comandi del database malevoliPresa totale del database
XSS (Cross-Site Scripting)Gli attaccanti possono iniettare script malevoliDirottamento di sessione, furto di dati
Segreti hardcodedChiavi API, password nel codicePresa del controllo degli account, gonfiaggio delle bollette
Validazione dell'Input MancanteNessun controllo degli input dell'utenteAttacchi di iniezione, arresti anomali
Autenticazione insicuraImplementazione debole dell'accessoAccesso non autorizzato

La violazione di Moltbook era in realtà due problemi: una chiave API hardcoded (segreti hardcoded) E RLS mancante (configurazione insicura). Ciascuno da solo sarebbe stato grave. Insieme, hanno creato una catastrofe.

Ciò che Nessuno Ti Dice Sul Vibe Coding

Sii onesto con te. Ho fatto molto vibe coding. Ha genuinamente cambiato il modo in cui costruisco le cose. Ma ho anche imparato alcune lezioni difficili a mie spese.

Devi comunque capire la sicurezza

Ecco una verità scomoda: non puoi usare strumenti AI per costruire applicazioni sicure se non capisci la sicurezza da solo. L'AI non conosce il tuo modello di minaccia. Non sa quali asset stai proteggendo. Genera semplicemente codice che sembra ragionevole.

Non devi diventare un esperto di sicurezza. Ma devi capire:

  • Non inserire mai segreti nel codice lato client
  • Abilita sempre il Row Level Security sui database
  • ❌ Curva di apprendimento — non adatto ai principianti
  • Implementa una validazione degli input appropriata
  • Esegui scansioni di sicurezza sul codice generato

Prototipo rapido, poi ingegneria

Il mio flusso di lavoro attuale:

  • Codifica vibe del prototipo — Fai funzionare qualcosa, convalida l'idea con utenti reali
  • Identifica il product-market fit — Prima di investire in qualsiasi cosa
  • Rifattorizza per la produzione — È qui che effettivamente ingegnerizzi sicurezza, prestazioni e manutenibilità

L'errore è spedire prototipi vibe-coded direttamente in produzione senza la fase di refactoring. Non stai risparmiando tempo — stai accumulando debito tecnico che ti costerà più tardi.

Usa lo strumento giusto per il lavoro

Questo potrebbe essere controverso, ma non penso che la programmazione vibe sia appropriata per:

  • Applicazioni che gestiscono dati utente sensibili (sanità, finanza)
  • Sistemi che elaborano pagamenti
  • Qualsiasi cosa con requisiti di conformità normativa
  • Applicazioni in cui errori di sicurezza possono causare danni reali

Per strumenti interni, MVP e prototipi? Vai avanti. Per sistemi di produzione che gestiscono dati utente reali? Ingegnerizzalo correttamente.

Come proteggersi

Se stai facendo vibe coding comunque (e onestamente dovresti farlo — è incredibilmente potente), ecco come evitare di diventare il prossimo titolo di cronaca:

Per il Tuo Supabase/Backend

javascript
// WRONG - Never do this const supabase = createClient('https://xxx.supabase.co', 'YOUR_ANON_KEY_HERE') // Your service_role key is also exposed here! // CORRECT - Use environment variables, server-side only const supabase = createClient( process.env.SUPABASE_URL, process.env.SUPABASE_ANON_KEY )

Checklist di sicurezza essenziale

  • [ ] Abilita la Sicurezza a Livello di Riga su TUTTE le tabelle del database
  • [ ] Salva le chiavi API nelle variabili d'ambiente, mai nel codice
  • [ ] Esegui una scansione di sicurezza su tutto il codice generato (Snyk, CodeQL o GitHub Advanced Security)
  • [ ] Never expose service_role keys a the client
  • [ ] Implementare una validazione degli input appropriata per tutti gli input utente
  • [ ] Configura limiti di frequenza per prevenire abusi
  • [ ] Esegui un penetration test prima di lanciare qualsiasi cosa con utenti reali

Strumenti Che Aiutano

StrumentoCosa faPiano gratuito
SnykScansione di sicurezza per il codiceSì
GitHub Advanced SecurityRilevamento vulnerabilitàSì (per i repository)
StackHawkTest di sicurezza APISì
DependabotVulnerabilità delle dipendenzeSì

Cosa significa per il settore

Sono sinceramente preoccupato per la direzione che stiamo prendendo.

Siamo nel mezzo di un enorme cambiamento nel modo in cui il software viene creato. I fondatori non tecnici possono ora creare applicazioni sofisticate. La soglia d'ingresso è crollata. È davvero entusiasmante.

Ma stiamo anche creando una generazione di applicazioni senza nessuno che controlli il negozio.

Ecco cosa penso debba succedere:

  • Gli strumenti di codifica AI hanno bisogno di migliori impostazioni di sicurezza — Smetti di generare codice con vulnerabilità integrate
  • Le comunità devono parlarne di più — Ogni articolo sul vibecoding dovrebbe menzionare la sicurezza
  • Abbiamo bisogno di strumenti migliori — La scansione di sicurezza automatizzata dovrebbe essere integrata in ogni flusso di lavoro di sviluppo AI
  • I fondatori devono assumersi la responsabilità — Non puoi incolpare l'AI quando qualcosa va storto

Il futuro dello sviluppo software non è scegliere tra velocità AI e sicurezza. È imparare a usare entrambi insieme.

Domande Frequenti

Gli strumenti AI possono risolvere i loro problemi di sicurezza?

Possono e stanno migliorando. Ma i modelli AI sono addestrati su codice esistente — che include codice insicuro. Essenzialmente stanno imparando cattive abitudini da tutto il corpus del software umano. Stiamo iniziando a vedere modelli addestrati specificamente su codice sicuro, ma non ci siamo ancora.

Gli strumenti AI possono risolvere i loro problemi di sicurezza?

Supabase va bene quando configurato correttamente. Il problema non era Supabase — era la configurazione di Moltbook (o la mancanza di essa). Supabase ha eccellenti funzionalità di sicurezza (come Row Level Security). Il problema era che lo sviluppo con AI portava a saltare queste funzionalità.

Supabase non è sicuro?

Assolutamente no. È un modo incredibilmente potente per costruire e iterare. Capisci semplicemente che "è stato fatto con il vibe coding" non è una scusa per fallimenti di sicurezza. Prototipa velocemente, convalida la tua idea, poi ingegnerizza per la produzione.

Should I stop vibe coding?

Sviluppo tradizionale con pratiche orientate alla sicurezza. Oppure: impara abbastanza da revisionare il codice generato dall'AI tu stesso. Oppure: assumi qualcuno per eseguire un audit di sicurezza prima del lancio. Oppure: utilizza strumenti e framework con solide impostazioni di sicurezza integrate.

Qual è l'alternativa al vibe coding?

Il verdetto finale

Moltbook non è un'anomalia. È un assaggio di ciò che viene.

Man mano che più fondatori distribuiscono applicazioni vibe-coded senza comprendere i fondamenti della sicurezza, vedremo più violazioni. Più chiavi API esposte. Più database scoperti. Più vittime.

Questo non è un argomento contro il vibe coding. È un argomento per essere onesti sulle sue limitazioni.

Pubblica velocemente. Testa le idee. Muoviti rapidamente. Ma prima di mettere i dati reali degli utenti a rischio, rallenta e fai il lavoro di sicurezza. I tuoi utenti ti affidano le loro informazioni. Questa fiducia non dovrebbe essere compromessa.

Post Correlati

Pronto a lanciare la tua app in sicurezza? Elenca la tua app su GetFree—una directory curata dove gli sviluppatori condividono codici promozionali e accesso beta con migliaia di tester mirati.

Fonti

Originariamente pubblicato su Blog GetFree.APP — Ultimo aggiornamento: 17 febbraio 2026

Hai apprezzato questo articolo? Condividilo con altri!

Condividi:

Pronto a scoprire app incredibili?

Trova e condividi le migliori app iOS gratuite con GetFree.APP

Inizia