Cinquemila app che perdono dati

Cos'è e perché conta

Il titolo del video viene dalle notizie. Secondo un'analisi riportata da Axios (maggio 2026), su circa 380.000 app pubblicate con strumenti AI, circa 5.000 esponevano dati sensibili. E TechCrunch (settembre 2026): la società UpGuard ha trovato circa 16.000 database su Supabase con dati personali accessibili. Quando leggo notizie così, la domanda che mi interessa è una sola: la mia è tra quelle? Usando l'app non lo vedi, perché a te da loggato i dati arrivano come devono. Lo sai solo se provi.

Il meccanismo, in breve. Tante app fatte con l'AI parlano direttamente con il database, tipo Supabase, dal browser o dal telefono. Per farlo si portano dietro l'indirizzo del progetto e una chiave pubblica, che chiunque può vedere. Va bene così: a proteggere i dati non è la chiave, sono le regole sul database. Su Supabase si chiamano Row Level Security. Se mancano, quella chiave apre le tabelle a tutti.

Ne ho già parlato nella guida PORTA (strikt.fit/porta), con i dettagli su Supabase, Firebase e le due chiavi. Qui c'è la versione da fare adesso: due prove da un minuto, il prompt che chiude e riprova, e come leggere il prima e dopo.

Solo sulla tua app

Questo test lo fai sulla tua app e sul tuo database, con account di prova. Mai sull'app di qualcun altro, nemmeno per vedere se è tra quelle cinquemila: leggere dati senza permesso può essere un reato, anche se la porta è aperta. Se pensi che un'app non tua sia esposta, avvisa chi la gestisce.

1. Senza login

La prima prova risponde a una domanda: cosa vede uno che non ha nessun account? Ci vuole un minuto.

1. Apri la tua app in una finestra in incognito, senza entrare. Così il browser non ha la tua sessione e sei un visitatore qualunque.
2. Tasto destro > Ispeziona > Rete (Network), poi ricarica la pagina.
3. Trova una richiesta che va a .supabase.co e cliccala. Lì vedi l'indirizzo del progetto e la chiave pubblica (publishable, o «anon» nei progetti più vecchi). È normale vederla: è fatta per stare nell'app.

Poi apri un terminale e lancia questa riga, con solo quei due dati. Metti il tuo progetto, la tua chiave e il nome di una tua tabella:

curl "https://TUO-PROGETTO.supabase.co/rest/v1/NOME_TABELLA?select=*" -H "apikey: CHIAVE_PUBBLICA"

Provala su ogni tabella con dati di persone: profili, messaggi, ordini, email. E fallo su tabelle che hanno davvero dei dati, perché una tabella vuota risponde [] anche se è aperta: controlla prima nel pannello di Supabase. Se tornano righe, chiunque le può leggere. Se da una tabella piena torna [] o un errore di permesso, quella tabella a chi passa non risponde.

2. Da utente A, i dati di B

La seconda prova è quella che si salta più spesso. La porta può essere chiusa a chi non ha fatto login e aperta a chiunque sia entrato. Un altro minuto.

1. Crea due account di prova, A e B.
2. Con ciascuno salva qualche dato: un profilo, una nota, un ordine.
3. Entra come A e prova ad aprire le righe di B, per esempio cambiando l'id nella richiesta o nell'indirizzo della pagina.

Se le vedi, le regole non ci sono. Oppure ci sono ma dicono «chi ha fatto login legge tutto», che per i dati personali non basta: il controllo giusto è su chi possiede la riga.

3. Il prompt per Claude Code

Quando sai cosa è aperto, lo fai chiudere. Apri Claude Code nella cartella del progetto e incolla questo:

Controlla ogni tabella del mio database Supabase: dimmi se ha la Row Level Security attiva e quali regole (policy) ha. Dove manca, attivala e scrivi le regole: ogni utente legge, crea, modifica e cancella solo le sue righe; le tabelle pubbliche per scelta solo in lettura. Non mettere mai la chiave segreta (secret o service_role) nel codice dell'app. Poi rifai il test: senza login con la chiave pubblica, e da utente A sulle righe di B. Mostrami tabella per tabella il risultato prima e dopo.

Ogni pezzo ha un motivo. «Legge, crea, modifica e cancella» perché su Supabase le regole si scrivono per ogni operazione: chiudere solo la lettura lascia aperto il resto. «Pubbliche per scelta» perché un catalogo può essere letto da tutti, ma deve essere una decisione tua, non un caso. E «rifai il test» perché una regola la verifichi provandola, non leggendola.

Claude controlla quello che può vedere. Se le tabelle sono nel codice del progetto, per esempio nei file di migrazione, le trova lì. Se le hai create a mano dal pannello di Supabase, digli tu quali sono, o fai i due test a mano e passagli il risultato. E se Claude Code ti chiede il permesso per lanciare un comando, leggi cosa sta per fare prima di dire sì.

Come leggere il prima e dopo

Il risultato ti conviene in una forma che si legge al volo. Puoi aggiungere al prompt «in una tabella così» e incollare questo schema:

Tabella | RLS prima | RLS dopo | Senza login prima | Senza login dopo | A su B prima | A su B dopo
profili | no | sì | righe | [] | righe | niente

A fine lavoro vuoi vedere tre cose: la Row Level Security attiva su ogni tabella, nessuna riga senza login tranne nelle tabelle pubbliche per scelta, e A che non vede niente di B. Se una tabella non torna così, chiedi a Claude perché prima di andare avanti.

Due cose da sapere

Meglio chiuso che aperto

Con la Row Level Security attiva e nessuna regola, dalla chiave pubblica non passa niente. Quindi meglio chiuso che aperto, poi apri solo quello che serve. Se dopo il fix una schermata smette di caricare, non spegnere la sicurezza: manca una regola. Fatti aggiungere quella:

La schermata [nome] non carica più i dati da quando hai attivato la Row Level Security. Trova quale regola manca e aggiungi la più stretta che basta. Non disattivare la sicurezza su nessuna tabella. Poi rifai i due test, senza login e da A verso B.

La chiave segreta

La chiave segreta (secret o service_role) salta tutte le regole. Sta solo sul server: mai nell'app, mai su GitHub. Se è finita nell'app o in un repository, cambiala subito dal pannello di Supabase. Toglierla dal codice non basta: resta nella cronologia e in chi l'ha già vista.

Non usi Supabase?

Fai lo stesso test con la tua piattaforma: senza login, poi da A verso B. I nomi cambiano, il concetto no. Su Firebase, per esempio, le regole si chiamano regole di sicurezza: cosa cercare e il prompt per controllarle li trovi nella guida PORTA.

Gli errori più comuni

• Fare il test da loggato. Usa una finestra in incognito, se no vedi i dati perché sei tu.
• Provare una sola tabella. Ogni tabella ha le sue regole: provale tutte, prima quelle con dati di persone.
• Fidarsi di un [] arrivato da una tabella vuota. Una tabella vuota risponde [] anche se è aperta: prova su una che ha dati.
• Fermarsi al test senza login. Fai anche quello da A verso B: è lì che si nasconde la regola «chi è loggato legge tutto».
• Spegnere la Row Level Security quando una schermata non carica. Aggiungi la regola che manca e lascia chiuso il resto.
• Fidarsi del fix senza riprovare. Rifai i due test e guarda il prima e dopo, tabella per tabella.

Checklist

• Test senza login, in incognito, su ogni tabella con dati di persone.
• Test da A verso B con due account di prova.
• Row Level Security attiva su ogni tabella, con regole per leggere, creare, modificare e cancellare.
• Tabelle pubbliche solo in lettura, e solo per scelta.
• Chiave segreta solo sul server, mai nell'app.
• I due test rifatti dopo il fix, con il prima e dopo sotto gli occhi.

Domande frequenti