La sicurezza delle app vibe-coded nel 2026

Sei numeri che raccontano la storia

Queste sei cifre sono il rapporto. Tutto quello che viene dopo è la base su cui poggia ciascuna, e come l'abbiamo ottenuta.

Le impostazioni predefinite delle piattaforme falliscono quasi ovunque, e la maggior parte di quei fallimenti è moderata. Quello che può cambiare solo chi ha costruito l'app fallisce molto più di rado, ed è quello che mette i dati di altre persone su internet aperta.

Che voto prendono queste app, dalla A alla F

Reeve dà un voto a un'app come fa una pagella. Le detrazioni partono da cento e pesano per gravità. Poi il riscontro più grave fissa un tetto: con un riscontro critico l'app non va oltre la D, con uno alto non va oltre la C.

La maggior parte delle app finisce in A o B. La fascia di D e F è piccola. Sono le app in cui uno sconosciuto può già leggere le righe di qualcun altro.

Cosa abbiamo controllato, e quante app hanno fallito ogni controllo

Ogni controllo fa una domanda sull'app vista da fuori, ed è contato sulle app in cui ha ottenuto una risposta. Un'app che un controllo non è riuscito a raggiungere resta fuori dalla base di quel controllo, invece di essere contata come pulita. Per quelle app la scansione dice che non è riuscita a controllarle, e questa pagina fa lo stesso.

Due righe fanno più paura di quanta ne meritino. Gli header di sicurezza sono istruzioni che la piattaforma di hosting manda al browser, e se ne manca uno una classe di attacchi si ritrova un ostacolo in meno davanti. Una source map pubblicata è il codice originale dell'app posato accanto alla versione compilata: mostra a un attaccante dove guardare, e da sola non consegna nulla.

Una riga può anche sembrare grave perché una manciata di app al suo interno ha spedito qualcosa di serio mentre le altre hanno spedito qualcosa di ordinario. Il file dei dati apre ogni riga per tipo di chiave, così si vede qual è quale.

Più della metà delle app Supabase controllabili lascia leggere i dati delle tabelle

È la cifra su cui siamo tornati di continuo.

Un progetto Supabase è aperto a internet per come è fatto. L'app che gira nel browser parla direttamente con il database, usando una chiave che deve essere pubblica, e ciò che sta fra uno sconosciuto e le righe è Row Level Security: una regola su ogni tabella. Disattiva quella regola, o scrivi una policy che fa entrare tutti, e qualsiasi tabella del progetto si legge con una richiesta e senza password.

Meno della metà delle app che nominano un progetto Supabase si riesce a controllare. Alcune mandano il traffico del database attraverso il proprio backend, dove un controllo da fuori non può seguirle, quindi su quelle non diciamo nulla. La quota qui sopra è calcolata sulle app che hanno risposto.

La divisione è la parte utile. Una tabella leggibile che si chiama settings o content è un errore. Una tabella leggibile che si chiama users, profiles o orders contiene dati personali di altre persone su internet aperta, e chi ha costruito l'app quasi certamente li crede privati.

Il controllo non legge mai una riga. Chiede al database quante righe sarebbero visibili e rilegge il conteggio da un header della risposta. Basta a distinguere una tabella con una regola RLS da una senza, e il controllo non va oltre.

Gli stessi nove controlli, strumento per strumento

Ogni app è raggruppata per lo strumento con cui è stata pubblicata, e misurata contro le altre app di quello strumento.

Quasi tutto ciò che questa tabella confronta sono impostazioni predefinite. Nessuno sceglie Lovable o Bolt per i suoi header di sicurezza. Li imposta la piattaforma per ogni app che ospita, quindi un solo cambiamento lì muove un'intera colonna di questa tabella.

Due limiti, prima che qualcuno citi una riga. Attribuiamo le app in base al dominio di pubblicazione, quindi un'app passata a un dominio personalizzato resta del tutto fuori da questa tabella, e spesso quelle sono le più finite. E uno strumento che instrada il traffico del database attraverso il proprio backend non è controllabile dall'esterno per niente. Un vuoto lì vuol dire che non siamo riusciti a misurare, e non dice nulla su quanto siano sicure quelle app.

Due tipi di riscontro, due tipi di correzione

I riscontri di questa pagina finiscono in due gruppi, e i due hanno bisogno di mani diverse.

Il primo gruppo è una decisione di prodotto presa in un'azienda. Una sola modifica a un'impostazione predefinita dell'hosting muove in un colpo tutte le app di quella piattaforma, ed è per questo che quelle righe vengono fuori così uniformi e sono le più economiche da correggere.

Il secondo gruppo è nelle mani di chi ha costruito l'app. Nessuna piattaforma di hosting può sapere quali delle tue tabelle devono essere pubbliche, né quale chiave sta su un server. Ogni riscontro critico di questo rapporto è in quel gruppo. Le guide di sicurezza per strumento e la checklist di lancio partono entrambe da lì.

Cosa fanno bene i vibe-coder

Abbiamo contato anche quello che passa, sulle stesse app.

L'ultima scheda è quella che gli scanner generici sbagliano. Una chiave pubblicabile nel frontend (una chiave anon di Supabase, una chiave pubblicabile di Stripe) è al suo posto: è fatta per essere letta, e la protezione sta nelle regole che le stanno dietro. Segnalarla manda qualcuno a cambiare un'impostazione che era già giusta.

Come abbiamo misurato, e dove sono i limiti

Usate questi numeri

Giornalisti, ricercatori e chiunque scriva di questo possono riusare i dati citando la fonte. Il file qui sotto contiene tutti gli aggregati di questa pagina in una sola tabella piatta, e non nomina nessuna app.