L'esposizione di dati Supabase mette sotto pressione le promesse di sicurezza delle app create con il vibe coding
Supabase è sotto esame dopo che i ricercatori hanno identificato 16.326 database con tabelle leggibili pubblicamente, nonostante la piattaforma descriva i propri progetti come sicuri per impostazione predefinita. I risultati sull'esposizione di dati in Supabase collegano un noto problema di sicurezza cloud a una fonte di rischio più recente: app assemblate rapidamente tramite strumenti di coding con IA.
UpGuard ha rilevato indicatori di informazioni personali in più della metà dei database esposti. I record interessati includevano, secondo quanto riferito, nomi, indirizzi, numeri di telefono, date di nascita, password, token di autenticazione, messaggi privati, targhe e informazioni sull'immigrazione.
Non si è trattato di una singola violazione dei sistemi interni di Supabase. Le prove indicano invece database dei clienti esposti a causa di controlli di accesso assenti o inadeguati. Questa distinzione è importante, ma non rende la portata del problema meno preoccupante.
Il rapporto trasforma un errore di configurazione tecnica in un banco di prova per il modello del vibe coding. Gli assistenti IA possono generare un'interfaccia funzionante e collegarla a un database ospitato in pochi minuti. Non garantiscono però in modo affidabile che ogni utente, tabella, ruolo e operazione riceva la corretta policy di autorizzazione.
Cosa ha rilevato la ricerca sull'esposizione di dati in Supabase
La conclusione centrale di UpGuard non riguarda una sola app insolitamente negligente, bensì migliaia di progetti sviluppati in modo indipendente che ripetono errori di sicurezza simili.
Per la sua indagine di settembre 2026, UpGuard ha raccolto circa 300.000 domini unici che mostravano segnali dell'uso di Supabase. I ricercatori hanno utilizzato dati di BuiltWith e del Chrome User Experience Report per identificare i siti pertinenti.
Hanno poi verificato se ciascun progetto esponeva una tabella chiamata users. Questo comune nome di tabella ha fornito ai ricercatori un punto di partenza coerente senza richiedere una conoscenza preliminare del design del database di ogni applicazione.
Il test ha prodotto diverse risposte possibili. Un database sicuro o inattivo non restituiva dati accessibili. Alcuni database rivelavano un'altra tabella accessibile attraverso un suggerimento di errore. Altri restituivano una pagina di record.
Nell'insieme dei candidati, UpGuard ha identificato 16.326 database con tabelle leggibili. Più della metà conteneva campi dello schema che suggerivano una qualche forma di informazioni di identificazione personale, secondo la ricerca sull'esposizione dell'azienda.
I ricercatori hanno analizzato principalmente gli schemi delle tabelle invece di scaricare ogni record disponibile. Uno schema rivela i nomi delle colonne e i tipi di dati, che possono indicare se una tabella contiene indirizzi email, password, numeri di telefono o informazioni di pagamento.
Questo approccio ha ridotto l'accesso non necessario a record personali. Significa inoltre che la cifra di 16.326 non stabilisce che ogni database contenesse informazioni sensibili o che gli aggressori abbiano precedentemente copiato i dati disponibili.
UpGuard ha indagato casi selezionati nei quali i metadati suggerivano un'esposizione significativa. Gli esempi mostrano come un errore di configurazione possa passare dal debito tecnico a un danno personale diretto.
Un servizio indiano di streaming per adulti ha esposto una tabella contenente dati di 65.467 persone. I campi riguardavano, secondo quanto riferito, documenti d'identità, indirizzi, date di nascita, conti finanziari e numeri parziali di identificazione governativa. Un'altra tabella conteneva oltre 100.000 messaggi privati che coinvolgevano creatori di contenuti.
Un operatore di SIM virtuali nelle Filippine ha esposto informazioni su oltre 2.000 utenti e più di 100.000 messaggi di testo. La maggior parte dei messaggi conteneva codici monouso, ma il campione includeva anche migliaia di comunicazioni ordinarie tra autisti e passeggeri di servizi di ride-hailing.
Un servizio di valet parking negli Stati Uniti ha esposto record relativi a oltre 100.000 clienti. Il suo database includeva circa 78.000 numeri di targa, circa 43.000 indirizzi email, cronologie delle visite, informazioni sulle mance e note in testo libero.
I ricercatori hanno inoltre trovato un database di un consolato governativo africano contenente 25.000 record. Alcune voci identificavano i luoghi di alloggio d'emergenza di persone appartenenti a una popolazione potenzialmente vulnerabile.
Un servizio canadese per l'immigrazione ha esposto quasi 5.000 record. UpGuard ha affermato che 884 includevano password archiviate in testo semplice, il che significa che l'applicazione aveva fallito sia nel controllo degli accessi sia nella gestione delle password.
Questi casi sostengono la conclusione più ampia, rivelando al tempo stesso diversi livelli di fallimento. L'accesso pubblico alle tabelle ha aperto la porta, ma una progettazione debole dell'applicazione ha reso i contenuti più pericolosi.
Il reporting originale ha indicato che la maggior parte dei dataset interessati sembrava collegata agli Stati Uniti. UpGuard ha comunque trovato progetti esposti in tutto il mondo e ha descritto il problema come globale.
La diffusione geografica è rilevante perché Supabase funge da infrastruttura comune per piccole applicazioni, nuove imprese e organizzazioni consolidate. Un singolo schema di configurazione ripetuto può quindi interessare utenti non correlati in vari settori e giurisdizioni legali.
Perché il database era raggiungibile dal web
La chiave pubblica all'interno di un'applicazione Supabase non è necessariamente la vulnerabilità. Il controllo decisivo è ciò che quella chiave è autorizzata a fare.
Supabase fornisce un database PostgreSQL ospitato insieme ad autenticazione, archiviazione e interfacce dati generate automaticamente. Un'applicazione web può effettuare richieste tramite la sua Data API usando una chiave pubblicabile.
Gli sviluppatori talvolta presumono che trovare questa chiave nel codice del browser dimostri che sia stata divulgata. Supabase progetta esplicitamente le chiavi pubblicabili per client pubblici, inclusi siti web e applicazioni mobili.
La protezione effettiva deriva dalle autorizzazioni e dalla Row Level Security, solitamente abbreviata in RLS. RLS è una funzionalità di PostgreSQL che applica regole di autorizzazione all'interno del database prima di restituire o modificare singole righe.
Un utente autenticato potrebbe ricevere il permesso di leggere soltanto record associati all'identificatore di quell'utente. Un visitatore non autenticato potrebbe non ricevere alcun accesso. Un'altra policy potrebbe consentire a tutti di leggere un catalogo prodotti deliberatamente pubblico.
La documentazione sulla sicurezza di Supabase afferma che gli sviluppatori devono abilitare RLS per le tabelle esposte e configurare le policy secondo il principio del privilegio minimo. La chiave pubblicabile è considerata sicura solo quando tali controlli limitano correttamente l'accesso.
La piattaforma fornisce inoltre chiavi segrete o con ruolo di servizio per sistemi backend attendibili. Queste chiavi aggirano RLS e non devono mai comparire in un browser, in un'applicazione distribuita o in un repository pubblico.
Questa architettura crea un confine di sicurezza sottile. Una chiave pubblicabile visibile è prevista, ma offre anche a un visitatore non autenticato una via verso tutto ciò a cui il database consente al ruolo anon di accedere.
Se una tabella non dispone di RLS, ha autorizzazioni eccessive o utilizza una policy che permette ogni riga, un esterno può interrogarla tramite la stessa interfaccia usata dall'app legittima. Non è richiesta alcuna intrusione sofisticata.
I ricercatori di UpGuard hanno individuato i progetti target esaminando JavaScript distribuito pubblicamente alla ricerca di identificatori Supabase. Hanno poi potuto chiedere a ciascun database se una tabella comune fosse disponibile tramite la sua interfaccia pubblica.
Questa tecnica assomiglia al normale comportamento di un'applicazione. La differenza sta in chi invia la richiesta e se il database è in grado di distinguere un utente autorizzato da chiunque altro su internet.
La dettagliata guida a RLS di Supabase avverte che una tabella in uno schema esposto può essere leggibile o scrivibile quando RLS è assente e il ruolo che effettua la richiesta dispone delle autorizzazioni appropriate. Raccomanda di testare sia le operazioni consentite sia quelle negate per i ruoli anonimi e autenticati.
Ecco perché la sola rotazione di una chiave pubblicabile non risolve il problema sottostante. La nuova chiave rimane recuperabile dal client, mentre la policy difettosa del database continua a concedere l'accesso.
Gli sviluppatori devono invece riesaminare gli schemi esposti, le autorizzazioni delle tabelle, lo stato RLS, le condizioni delle policy, le viste del database e le credenziali server. Devono inoltre eseguire test che confermino che gli utenti non possano leggere o modificare i record di un altro utente.
Le viste meritano particolare attenzione. Per impostazione predefinita, le viste PostgreSQL possono valutare i permessi tramite il loro proprietario, aggirando potenzialmente le restrizioni che proteggono le tabelle sottostanti. Un progetto può quindi abilitare RLS ovunque e continuare comunque a divulgare dati attraverso una vista non sicura.
La stessa distinzione si applica all'autenticazione. Richiedere l'accesso a qualcuno non mantiene automaticamente separati gli utenti di diversi tenant. Ogni utente autenticato può comunque ottenere un accesso ampio se la policy verifica soltanto l'esistenza di una sessione valida.
La sicurezza di Supabase spiegata a livello di chiavi è quindi semplice. I client pubblici necessitano di un identificatore pubblico, mentre le policy del database impongono il vero confine. La difficoltà consiste nel tradurre le regole previste dall'applicazione in policy complete e testate.
Il vibe coding trasforma una lacuna di configurazione in uno schema ricorrente
I rischi di sicurezza del vibe coding aumentano quando un assistente IA ottimizza per un risultato visibile mentre l'autorizzazione rimane nascosta alla persona che lo dirige.
Anche un team di sviluppo convenzionale può configurare erroneamente un database. Bucket Amazon S3 pubblici, cluster Elasticsearch esposti e credenziali cloud divulgate esistevano molto prima che l'IA generativa entrasse nello sviluppo software.
Ciò che cambia con il vibe coding è la combinazione di velocità, accessibilità e revisione limitata. Una persona può richiedere un'app in linguaggio naturale, accettare il codice generato, collegare un backend ospitato e distribuirla senza comprendere i confini di fiducia.
L'applicazione può sembrare completa perché la registrazione funziona, i record vengono salvati correttamente e le pagine si caricano. Questi test confermano la funzionalità. Non confermano che un account non possa interrogare i record di un altro account.
I fallimenti nell'autorizzazione sono particolarmente facili da non rilevare durante una dimostrazione del percorso ideale. Lo sviluppatore vede il profilo previsto dopo l'accesso e presume che il sistema lo abbia protetto. Un aggressore pone una domanda diversa: cosa accade quando la richiesta omette una sessione o modifica un identificatore di record?
Gli agenti di coding IA interagiscono inoltre con l'infrastruttura in modo programmatico. UpGuard ha osservato che Supabase abilita RLS per impostazione predefinita per le tabelle create tramite alcune parti della sua dashboard, mentre le tabelle create programmaticamente richiedono ulteriore attenzione.
Questa differenza può diventare significativa quando un agente crea uno schema di database tramite SQL o un'API. Un'impostazione protettiva associata a un flusso di creazione non copre automaticamente ogni percorso di accesso alla piattaforma.
Supabase ha riconosciuto questa più ampia sfida di usabilità nella sua revisione della sicurezza del 2025. L'azienda ha affermato che RLS è flessibile, ma può risultare complessa per sviluppatori che non conoscono questo modello.
Nel corso del 2025, Supabase ha aggiunto impostazioni predefinite più sicure e ampliato il proprio Security Advisor. Ha inoltre offerto ai progetti maggiore controllo sulla Data API, inclusa l'opzione di disabilitarla o di esporre uno schema personalizzato anziché lo schema predefinito public.
Questi cambiamenti aiutano, ma non eliminano i progetti esistenti né correggono ogni migrazione generata. Gli strumenti di sicurezza possono segnalare errori comuni, ma una policy può rimanere logicamente errata pur superando un controllo di base.
Una regola generata potrebbe confrontare l'identificatore sbagliato, trascurare un percorso di aggiornamento o proteggere le letture consentendo al contempo scritture non autorizzate. Potrebbe funzionare per una tabella ma lasciare pubblica una tabella correlata.
Il supervisore umano dell’agente deve riconoscere che quel comportamento mancante esiste. Un principiante che non conosce RLS, assegnazioni di ruoli o isolamento dei tenant potrebbe non chiedere mai al modello di verificarli.
Questo crea un’asimmetria tra sviluppo e audit. Generare una funzionalità richiede un solo prompt. Dimostrare che la funzionalità gestisce in modo sicuro ogni identità e operazione richiede un modello delle minacce, test negativi e un attento esame degli artefatti generati.
Studi precedenti suggeriscono che si tratti di un modello ricorrente, non di un risultato isolato di una singola indagine. UpGuard ha citato ricerche che coinvolgevano aziende di Y Combinator, app create tramite piattaforme di sviluppo AI e siti indipendenti.
Modern Pentest ha riferito che il 28 percento di 107 startup di Y Combinator esaminate esponeva informazioni personali tramite configurazioni Supabase. Un altro studio ha analizzato 1.072 app sviluppate con vibe coding e ne ha trovate 39 con tabelle leggibili tramite una chiave Supabase pubblica.
I campioni e i metodi differiscono, quindi le rispettive percentuali non vanno combinate. Tuttavia, ogni indagine ha individuato varianti dello stesso problema: informazioni di connessione visibili al client abbinate a permessi del database più estesi di quanto previsto dall’applicazione.
Un incidente del febbraio 2026 ha reso le conseguenze particolarmente evidenti. La società di sicurezza Wiz ha scoperto che Moltbook, un social network presentato come piattaforma per agenti AI, aveva un backend Supabase configurato in modo errato.
Secondo l’indagine su Moltbook, il database consentiva accesso in lettura e scrittura ai dati della piattaforma. Il materiale esposto comprendeva 35.000 indirizzi email e 1,5 milioni di token di autenticazione API.
Wiz ha dichiarato di aver individuato il problema esaminando JavaScript lato client durante una valutazione non intrusiva. Il team di Moltbook ha protetto il database entro poche ore dalla segnalazione.
L’episodio ha offerto un esempio conciso dell’attuale compromesso. L’assistenza AI ha contribuito a produrre rapidamente un servizio capace di attirare attenzione, ma il successo visibile dell’applicazione nascondeva un grave fallimento dei controlli sul database.
Per le organizzazioni che valutano software realizzato con AI, questo cambia il significato di un prototipo funzionante. Una dimostrazione oggi prova meno in termini di idoneità alla produzione, perché l’AI può completare flussi di lavoro visibili prima che qualcuno convalidi il modello di sicurezza sottostante.
Una knowledge base ingegneristica interna può aiutare i team a conservare decisioni architetturali e prove di revisione. Non può sostituire i test sul database, ma può evitare che le ipotesi di sicurezza scompaiano tra prompt e passaggi di consegne.
“Secure by Default” incontra la responsabilità condivisa
Il conflitto principale riguarda impostazioni predefinite sicure della piattaforma e un modello di responsabilità condivisa che lascia comunque a clienti inesperti il controllo di configurazioni dalle conseguenze rilevanti.
Il Chief Information Security Officer di Supabase, Bil Harmer, ha dichiarato a TechCrunch che l’azienda non aveva esaminato la ricerca di UpGuard prima di commentare. Ha affermato che i progetti Supabase sono sicuri per impostazione predefinita e ha descritto la sicurezza come una responsabilità condivisa.
Questa posizione riflette un modello cloud standard. Il fornitore protegge la propria piattaforma ospitata e offre controlli di accesso. I clienti decidono quali utenti e applicazioni debbano raggiungere i loro dati.
La distinzione è valida. UpGuard non ha segnalato compromissioni dei sistemi aziendali di Supabase né l’aggiramento di una policy RLS configurata correttamente. I database esposti appartenevano a clienti le cui impostazioni consentivano un accesso più ampio.
Tuttavia, le impostazioni predefinite non possono essere valutate solo al momento della creazione di un progetto. Comprendono anche i percorsi pratici che persone e agenti di coding usano per creare tabelle, pubblicare API, copiare esempi e distribuire applicazioni.
Un sistema può iniziare in modo sicuro ed esporsi successivamente tramite una migrazione generata da un agente. Può anche offrire un flusso sicuro tramite dashboard mentre un flusso programmatico crea uno stato di sicurezza differente.
L’espressione “secure by default” necessita quindi di un confine definito. Significa che un nuovo progetto non espone nulla? Copre ogni percorso supportato per la creazione delle tabelle? Avvisa gli utenti prima che dati di produzione entrino in una tabella senza RLS?
La responsabilità condivisa presuppone inoltre che ogni parte comprenda il proprio incarico. Gli ingegneri cloud esperti sanno che un identificatore pubblico del client deve essere abbinato all’autorizzazione lato server. Molti vibe coder non lo sanno.
Questo divario di conoscenza non rende la piattaforma l’unica responsabile degli errori dei clienti. Aumenta però la pressione su Supabase e sui fornitori di AI per il coding affinché rendano gli stati non sicuri più difficili da creare e più facili da rilevare.
La piattaforma si è già mossa in questa direzione. Security Advisor di Supabase controlla i problemi comuni del database, mentre la checklist per la produzione invita gli utenti ad abilitare RLS su tutte le tabelle pertinenti e a rivedere le policy.
Un design più rigoroso potrebbe bloccare l’accesso in produzione a una tabella non protetta oppure richiedere un override esplicito. Misure del genere ridurrebbero le esposizioni accidentali, ma potrebbero anche ostacolare dataset pubblici legittimi e lo sviluppo rapido.
Supabase deve bilanciare questi casi senza trattare ogni tabella pubblica come una vulnerabilità. Il menu di un ristorante, una classifica pubblica o una directory pubblicata possono ragionevolmente consentire letture anonime.
La piattaforma non può dedurre l’intento dal solo nome di una tabella. Una tabella users è più sospetta di una tabella products, ma un’applicazione potrebbe pubblicare intenzionalmente profili utente mantenendo privati gli indirizzi email.
Gli strumenti automatizzati affrontano la stessa ambiguità. Possono rilevare che un ruolo anonimo è in grado di leggere una tabella. Stabilire se l’accesso viola la promessa del prodotto richiede il contesto aziendale.
Questo è il compromesso fondamentale. Policy flessibili per il database consentono agli sviluppatori di creare molti tipi di applicazioni, ma la flessibilità lascia spazio a errori silenziosi. Restrizioni prescrittive prevengono gli errori limitando però i design legittimi.
Gli assistenti AI aggiungono un’altra parte responsabile. Uno sviluppatore potrebbe scegliere Supabase perché consigliato da un agente, per poi affidarsi a quell’agente per generare schema e policy.
Il fornitore del modello non ospita il database, mentre Supabase non controlla ogni comando generato. Il proprietario dell’app resta responsabile verso gli utenti, anche quando non sa spiegare il modello di autorizzazione risultante.
Questa catena frammentata rende i fallimenti di sicurezza più difficili da attribuire e più facili da ripetere. Ogni partecipante può richiamarsi alla documentazione o alla configurazione di un’altra parte, mentre la persona colpita vede soltanto che informazioni private sono diventate pubbliche.
Per gli acquirenti aziendali, la risposta pratica consiste nel valutare l’intero sistema di sviluppo. Le certificazioni dei fornitori contano, ma contano anche i controlli di distribuzione, la revisione del codice, i test sul database, il logging, la risposta agli incidenti e l’esperienza delle persone che supervisionano gli agenti AI.
Cosa mostrano i numeri, e cosa non mostrano
Lo studio dimostra un’ampia superficie di esposizione, ma la sua metodologia non stabilisce 16.326 violazioni confermate né misura l’intera base clienti di Supabase.
UpGuard è partita da domini che mostravano indicatori dell’uso di Supabase, non da un campione casuale di ogni applicazione sulla piattaforma. Le sue fonti privilegiavano siti visibili attraverso dataset sulle tecnologie web.
I ricercatori hanno quindi eseguito query per una tabella denominata users. La scelta era sensata perché molte applicazioni mantengono registri degli utenti, ma ha anche orientato l’indagine verso database probabilmente contenenti informazioni personali.
UpGuard ha dichiarato questo limite. L’azienda ha affermato che i risultati erano sbilanciati verso i dati personali identificabili, in parte perché aveva scelto deliberatamente una tabella comune associata alle persone.
Il totale di 16.326 riguarda database che esponevano tabelle leggibili. Non significa che ogni tabella contenesse record riservati. Alcuni progetti potrebbero aver pubblicato intenzionalmente dati, utilizzato informazioni sintetiche o essere stati abbandonati.
L’analisi dello schema misura inoltre l’esposizione potenziale in modo diverso da un’indagine forense riga per riga. Una colonna denominata password è un serio segnale d’allarme, ma la sua sola esistenza non dimostra che contenesse credenziali attive.
I ricercatori hanno convalidato manualmente casi selezionati e riportato conteggi concreti di record da quei database. Questi esempi dimostrano che almeno alcune esposizioni coinvolgevano dati reali e sensibili su scala significativa.
La ricerca non può inoltre determinare quanti soggetti esterni abbiano avuto accesso ai database prima della segnalazione. La disponibilità pubblica crea un rischio, ma non prova che attori criminali abbiano scoperto o scaricato le informazioni.
Questa differenza separa un’esposizione di dati da una violazione dei dati confermata. Un’esposizione significa che un accesso non autorizzato era possibile. Una violazione richiede generalmente prove che una parte non autorizzata abbia effettivamente avuto accesso ai dati o li abbia acquisiti.
Le organizzazioni non dovrebbero usare questa distinzione per minimizzare l’evento. Una volta che record sensibili sono raggiungibili senza un’autorizzazione adeguata, gli investigatori potrebbero non disporre di log sufficienti per dimostrare chi vi abbia avuto accesso.
Lo studio non calcola nemmeno un tasso di esposizione sull’insieme dei progetti Supabase. UpGuard ha analizzato circa 300.000 domini candidati, mentre una singola organizzazione può gestire più domini o progetti.
Siti inattivi e falsi indicatori tecnologici possono complicare quel denominatore. Il numero finale va inteso soprattutto come una popolazione individuata, non come una percentuale dei clienti Supabase.
Anche con queste cautele, 16.326 database leggibili rappresentano una superficie d’attacco sostanziale. Un attore malevolo potrebbe automatizzare lo stesso processo generale di scoperta e dare priorità alle tabelle contenenti campi di valore.
I casi dettagliati indeboliscono inoltre l’argomento secondo cui si trattasse di innocui progetti dimostrativi. Registri sull’immigrazione, località di alloggi di emergenza, comunicazioni private per adulti, targhe automobilistiche e codici monouso comportano chiare implicazioni per privacy e sicurezza.
La risposta di Supabase merita la stessa precisione. L’azienda ha dichiarato di notificare i clienti coinvolti quando viene a conoscenza di problemi di sicurezza. Ciò non conferma quanti progetti siano stati notificati, con quale rapidità abbiano risposto o quante esposizioni siano rimaste aperte.
UpGuard ha dichiarato di aver notificato i proprietari delle applicazioni nei casi significativi che aveva convalidato. Il suo rapporto pubblico non ha fornito un tasso di risanamento completo per tutti i 16.326 database.
Queste lacune dovrebbero orientare la copertura dei risultati. Le prove supportano l’esistenza di un problema di configurazione diffuso e di varie esposizioni gravi. Non supportano l’affermazione che Supabase stessa sia stata violata o che ogni database identificato abbia divulgato record sensibili.
Resta inoltre senza risposta un’importante questione comparativa. Database ospitati comparabili potrebbero mostrare problemi simili se i ricercatori applicassero un metodo equivalente su scala internet.
Firebase, Appwrite, deployment PostgreSQL autogestiti e altri servizi backend espongono interfacce diverse e utilizzano modelli di autorizzazione differenti. Gli sviluppatori possono configurare erroneamente ciascuno di essi.
Supabase attira attenzione perché la sua architettura favorevole al client, le API automatiche e la popolarità nei flussi di lavoro di coding AI rendono il problema visibile. La popolarità aumenta sia il numero di deployment sicuri sia il numero di errori.
Una valutazione equa dovrebbe quindi evitare di presentare Supabase come un soggetto unicamente incapace di proteggere i dati. La conclusione più solida è che la sua adozione tra sviluppatori inesperti rende l’usabilità dei controlli di accesso una questione a livello di piattaforma.
Tre segnali mostreranno se il rischio si sta riducendo
La prossima fase dovrebbe essere valutata attraverso cambiamenti misurabili del prodotto, prove di risanamento e nuovi test indipendenti, anziché mediante ampie promesse sulla sicurezza.
Il primo segnale riguarda il modo in cui Supabase gestisce le tabelle create programmaticamente. Gli agenti di coding lavorano comunemente tramite SQL, interfacce di gestione e migrazioni automatizzate, piuttosto che mediante clic manuali nella dashboard.
Un cambiamento significativo renderebbe RLS e le assegnazioni restrittive coerenti tra i diversi percorsi di creazione, oppure richiederebbe una decisione esplicita prima che una tabella diventi raggiungibile tramite la Data API. Avvisi chiari all’interno dei flussi di lavoro degli agenti rafforzerebbero questa protezione.
Se Supabase colmerà il divario tra la creazione tramite dashboard e quella programmatica, rafforzerà l’idea che impostazioni predefinite più sicure possano ridurre i rischi di sicurezza del vibe coding. Se i flussi di lavoro rimarranno diversi, gli sviluppatori meno esperti continueranno a trovarsi in situazioni non sicure senza rendersene conto.
Il secondo segnale riguarda i dati sulla mitigazione. Supabase e UpGuard possono chiarire quanti progetti identificati abbiano ricevuto avvisi, quanti proprietari abbiano risposto e quanti database abbiano smesso di esporre record non intenzionalmente accessibili.
Un tasso elevato di mitigazione dimostrerebbe che notifiche e strumenti di sicurezza possono ridurre l’arretrato esistente. Un tasso basso suggerirebbe invece che molti progetti sono abbandonati, mantenuti in modo inadeguato o gestiti da persone incapaci di correggere la configurazione.
Le organizzazioni coinvolte devono anche stabilire se i record esposti richiedano una notifica agli utenti o una segnalazione alle autorità competenti. Questa decisione dipende dalla località, dal tipo di dati, dalle evidenze di accesso e dalla normativa applicabile.
Il terzo segnale sarà il riesame indipendente nei prossimi mesi. I ricercatori dovrebbero ripetere scansioni comparabili e pubblicare metodi trasparenti che distinguano i dati intenzionalmente pubblici dall’esposizione di informazioni sensibili.
Un calo del numero di database sosterrebbe la strategia di Supabase basata su impostazioni predefinite più sicure. Un numero stabile o in aumento indicherebbe che la crescita della piattaforma e lo sviluppo assistito dall’IA stanno creando progetti insicuri più rapidamente di quanto i controlli esistenti riescano a correggerli.
Anche i fornitori di strumenti di programmazione con IA meritano attenzione durante queste nuove verifiche. I loro agenti dovrebbero creare policy a privilegio minimo, generare test di autorizzazione negativi e avvisare quando un deployment espone informazioni personali.
Gli sviluppatori non devono abbandonare Supabase o la programmazione con IA per reagire in modo responsabile. Devono considerare il software generato come non attendibile finché il suo comportamento in materia di autorizzazioni non sia stato testato.
Ciò significa verificare separatamente l’accesso anonimo e quello autenticato, testare ogni operazione sul database, esaminare le viste, proteggere le chiavi server e disabilitare le interfacce di cui l’applicazione non ha bisogno.
I team dovrebbero inoltre conservare le decisioni alla base di tali controlli. Una base di conoscenza AI ricercabile può collegare requisiti, migrazioni generate, risultati degli audit e attività di mitigazione, senza trasformare la documentazione in un elemento secondario.
La vicenda dell’esposizione dei dati di Supabase riguarda, in ultima analisi, un divario di responsabilità. Le piattaforme offrono controlli configurabili, gli agenti IA assemblano applicazioni e gli utenti si fidano dell’interfaccia finale.
Chi verifica le autorizzazioni invisibili prima che informazioni reali entrino nel sistema? Qualsiasi organizzazione che rilasci un’app generata dall’IA dovrebbe poter rispondere a questa domanda con risultati dei test, responsabili nominati e prove di accesso negato.
