Come rendere sicura un’app creata con il vibe coding prima di condividerla
Risposta breve
Prima che i colleghi usino un’app che hai creato con l’AI, verifica quattro cose: nessuno passa senza il login aziendale, entrano solo gli account della tua azienda, nel codice che gira nel browser non ci sono chiavi, e il database non si può leggere senza passare dall’app. Poi verifica chi può fare cosa al suo interno, e chi ne è responsabile quando te ne vai.
La maggior parte delle fughe di dati dalle app create con l’AI non sono attacchi ingegnosi. Sono porte aperte: un link pubblico, un database con le regole disattivate, una chiave nella pagina. Questa checklist è per chi ha creato l’app e per chi nell’IT la revisiona. Ogni punto dice cosa va storto, come verificarlo con parole semplici, e cosa gestisce TeamOnly e cosa resta a te.
Ultimo aggiornamento Scritto da TeamOnly. Ospitiamo app interne create con l’AI, e ogni punto dice onestamente dove aiutiamo e dove no.
01Perché conta
Cosa va storto con le app create con l’AI
Gli strumenti AI sono bravi a far funzionare un’app. Sono meno attenti a chi altro può usarla. Tre risultati degli ultimi due anni mostrano lo schema.
380.000
risorse raggiungibili pubblicamente trovate su Lovable, Base44, Netlify e Replit dall’azienda di sicurezza Red Access a maggio 2026. Circa 5.000 contenevano dati aziendali sensibili, e molte erano indicizzate da Google.
170 su 1.645
app Lovable verificate a marzo 2025 permettevano a chiunque di leggere o modificare i dati nel loro database Supabase senza accedere, perché le regole di accesso al database mancavano o erano sbagliate (CVE-2025-48757).
205.474
nomi di pacchetti inventati suggeriti da 16 modelli AI su 576.000 esempi di codice, in uno studio del 2025. Chi attacca può pubblicare pacchetti con quei nomi e aspettare che qualcuno li installi.
Per nessuno di questi serviva un attaccante ingegnoso. Le porte erano aperte. È una buona notizia: le porte aperte si verificano facilmente, e non serve leggere il codice per farlo.
Falle in ordine. Le prime tengono fuori gli estranei, le successive scoprono gli errori dentro l’azienda.
Non si carica niente prima del login aziendale
Cosa va storto
Gli strumenti AI spesso creano la schermata di accesso come una pagina dell’app. Il resto dell’app, e la sua API, rispondono comunque a chiunque salti quella pagina o chiami direttamente l’API. Red Access ha trovato app aziendali che davano accesso da amministratore a chiunque arrivasse all’indirizzo.
Verificalo da solo
Apri l’app in una finestra privata del browser. Dovresti vedere una schermata di accesso e nient’altro. Poi chiedi al tuo strumento AI: “Elenca tutte le route dell’API e dimmi quali funzionano senza accesso.” La risposta dovrebbe essere nessuna.
Su TeamOnly
Gestito. Ogni richiesta a ogni app viene verificata prima che giri qualsiasi parte del tuo codice, comprese le chiamate API, che ricevono un 401 senza sessione. Non esiste un’impostazione per rendere pubblica un’app.
Entrano solo gli account della tua azienda
Cosa va storto
“Accedi con Google” di default fa entrare qualsiasi account Google, compreso il Gmail personale. L’impostazione hd di Google restringe solo la scelta dell’account, e Google avverte di non farci affidamento perché la richiesta può essere modificata. Il dominio va verificato sul server.
Verificalo da solo
Prova ad accedere con un account Gmail o Outlook personale. Dovresti essere respinto. Chiedi al tuo strumento AI dove il server verifica il dominio dell’email, e se verifica il token firmato da Google o un valore inviato dal browser.
Su TeamOnly
Gestito. I colleghi accedono con l’account Google di lavoro, Microsoft di lavoro o un codice inviato all’email aziendale. Il dominio nel token di accesso verificato viene confrontato con i domini della tua azienda, e gli account personali vengono rifiutati.
Solo le persone giuste dentro l’azienda
Cosa va storto
Un’app con stipendi, valutazioni o dati dei clienti viene condivisa con tutta l’azienda perché era l’impostazione predefinita. Oppure l’AI costruisce nel codice una sua lista di accesso che nessuno aggiorna.
Verificalo da solo
Chiediti: tutti in azienda dovrebbero vedere questi dati? Se no, scrivi i nomi delle persone che dovrebbero vederli, e verifica che chi è fuori da quella lista venga respinto.
Su TeamOnly
Gestito, scegli tu. L’accesso è per tutta l’azienda o per una lista di nomi, impostato nella dashboard o con npx teamonly access only priya@acme.com. Viene verificato a ogni richiesta, quindi rimuovere qualcuno ha effetto entro un minuto.
Non su un link pubblico, non nei risultati di ricerca
Cosa va storto
Alcuni builder di app pubblicano a un indirizzo pubblico a meno che tu non scelga privato. Le app pubbliche vengono trovate: Red Access ha riferito che molte delle app aziendali esposte erano indicizzate da Google e da altri motori di ricerca.
Verificalo da solo
Cerca su Google site: seguito dall’indirizzo della tua app. Controlla l’impostazione di visibilità del progetto sulla piattaforma con cui l’hai creata. Se dice pubblico, cambiala prima di tutto il resto.
Su TeamOnly
Gestito. Le app stanno su yourapp.yourcompany.teamonly.app dietro la schermata di accesso. Ogni risposta, compresa la schermata di accesso, dice ai motori di ricerca di non indicizzarla, e la schermata di accesso mostra solo il nome dell’app e i modi per accedere.
Nessuna chiave nel codice che gira nel browser
Cosa va storto
Gli strumenti AI mettono chiavi API nel codice React o in variabili che iniziano con VITE_ o NEXT_PUBLIC_. Tutto ciò che viene inviato al browser può essere letto da chiunque apra l’app. Supabase dice che la sua chiave segreta non deve mai stare in un browser, perché salta ogni regola del database.
Verificalo da solo
Chiedi al tuo strumento AI: “C’è qualche chiave, token o password nel codice front end, in una variabile VITE_ o in un file .env committato?” Nel browser, apri gli strumenti per sviluppatori e cerca nei file caricati key, secret e sk_. Se una chiave è mai stata esposta, cambiala presso il servizio che l’ha emessa.
Su TeamOnly
In parte gestito. Le chiavi si salvano con npx teamonly secrets set NAME, fuori dal codice, e solo il codice server della tua app può leggerle. Le istruzioni che TeamOnly aggiunge dicono al tuo strumento AI di non usare mai chiavi VITE_. Niente ti impedisce di incollare tu stesso una chiave nel codice, quindi verifica comunque.
Il database non si può leggere aggirando l’app
Cosa va storto
Con Supabase e servizi simili, il browser parla direttamente con il database e le regole di accesso (row-level security) decidono cosa può vedere. Quando quelle regole sono disattivate o sbagliate, chiunque abbia la chiave pubblica può leggere o modificare tabelle intere. È stato il caso di Lovable.
Verificalo da solo
In Supabase, apri Advisors, poi Security Advisor. Qualsiasi errore “RLS disabled in public” indica una tabella che chiunque può leggere. Che una regola esista non basta: accedi come un collega qualsiasi e prova ad aprire il record di qualcun altro.
Su TeamOnly
Gestito per gli esterni. Il database di ogni app non ha un suo indirizzo su internet. È raggiungibile solo tramite il codice server della tua app, dopo l’accesso. Quali righe può vedere ogni persona che ha fatto l’accesso resta compito del codice della tua app (vedi la verifica 8).
I dati di ogni app tenuti separati
Cosa va storto
Più app condividono un database o un bucket di archiviazione perché era più veloce. Poi una chiave o un bug in un’app le apre tutte.
Verificalo da solo
Chiediti: qualche altra app usa lo stesso database, la stessa archiviazione o le stesse chiavi di questa? Se sì, è l’app più debole a decidere quanto sono sicure tutte.
Su TeamOnly
Gestito. Ogni app riceve il suo database, la sua archiviazione file e i suoi segreti alla prima pubblicazione, e il suo cookie di sessione è legato al suo indirizzo. Le app non possono raggiungere i dati delle altre.
Chi può fare cosa, verificato sul server
Cosa va storto
L’AI nasconde il pulsante Approva alla maggior parte delle persone ma lascia la route di approvazione aperta a chiunque abbia fatto l’accesso. Oppure il server si fida di un ruolo o di un’email inviati dal browser. Il controllo degli accessi difettoso è al primo posto nella OWASP Top 10. L’input non verificato è un parente stretto: un importo negativo, una query SQL costruita da una casella di testo.
Verificalo da solo
Accedi come un collega qualsiasi e prova a fare ciò che dovrebbero fare solo i responsabili. Chiedi al tuo strumento AI: “Per ogni route dell’API, chi può chiamarla, e in quale punto del server viene verificato? Tutte le query al database usano i segnaposto?”
Su TeamOnly
In parte gestito. La tua app riceve la persona verificata (ctx.user) e i ruoli che assegni nella dashboard (ctx.user.roles), e gli header di identità falsificati vengono rimossi. Le istruzioni dicono al tuo strumento AI di usare i segnaposto nelle query e di verificare l’input sul server. Verificare il ruolo in ogni route spetta al codice della tua app. TeamOnly non lo revisiona.
Ogni pacchetto è reale e necessario
Cosa va storto
Gli strumenti AI a volte suggeriscono pacchetti che non esistono. Chi attacca pubblica pacchetti con quei nomi, così installarne uno esegue il codice di uno sconosciuto dentro la tua app.
Verificalo da solo
Apri package.json. Per ogni nome che non riconosci, cercalo su npmjs.com: un pacchetto reale ha una storia, un repository del codice collegato e download costanti. Esegui npm audit prima di pubblicare, e rimuovi i pacchetti che l’app non usa più.
Su TeamOnly
Non gestito. TeamOnly non analizza i pacchetti. Un’app può raggiungere solo i suoi dati e le sue chiavi, il che limita cosa può toccare un pacchetto malevolo, ma dentro quell’app potrebbe comunque leggere tutto.
Un registro di chi ha cambiato cosa
Cosa va storto
Qualcosa viene approvato, eliminato o modificato e nessuno sa dire chi l’ha fatto. Le app create con l’AI raramente tengono uno storico se non lo chiedi.
Verificalo da solo
Chiedi al tuo strumento AI di registrare chi ha creato e chi ha modificato per ultimo ogni record, e quando, e di tenere una tabella di storico per approvazioni ed eliminazioni. Provalo: modifica un record, poi cerca il tuo nome sopra.
Su TeamOnly
In parte gestito. La dashboard mostra ogni pubblicazione di ogni app, con chi l’ha pubblicata e quando, e i log in tempo reale. I log sono in tempo reale, non archiviati. I log di audit degli accessi e delle modifiche ai permessi sono nel piano Business, configurati insieme a te. Lo storico dentro l’app (chi ha approvato una spesa) è compito della tua app.
Un responsabile, un backup e un piano per chi se ne va
Cosa va storto
Chi l’ha creata se ne va e l’app continua a girare sul suo account personale, o si ferma quando la sua carta viene annullata. Oppure una modifica sbagliata cancella una tabella e non c’è una copia.
Verificalo da solo
Scrivi chi è il responsabile dell’app e chi subentra. Tieni il codice in un repository Git aziendale. Chiedi al tuo strumento AI di aggiungere un’esportazione CSV delle tabelle principali, e provala.
Su TeamOnly
In parte gestito. Le app appartengono alla tua azienda, e gli admin possono passare un’app a un nuovo responsabile. Disattivare l’account di lavoro di qualcuno blocca i nuovi accessi. Chi ha già fatto l’accesso resta dentro finché la sessione non scade, e gli admin scelgono quanto dura, da 8 ore a 30 giorni. Oggi nella dashboard non c’è un pulsante di backup o di esportazione, quindi integra l’esportazione nell’app.
03Da stampare
La verifica in un minuto
Undici domande a cui rispondere sì o no. Ogni “no” è la prossima cosa da sistemare.
Prima di condividere questa app
Una finestra privata del browser mostra un accesso aziendale e nient’altro.
Un account Gmail o Outlook personale viene respinto.
Possono aprirla solo le persone che hanno bisogno di questi dati.
Una ricerca site: per l’indirizzo dell’app non trova niente.
Nessuna chiave, token o password sta nel codice del browser o nel repository.
Il database non è raggiungibile senza passare dall’app.
I dati e le chiavi di questa app non sono condivisi con nessun’altra app.
Un collega qualsiasi non può fare ciò che dovrebbero fare solo i responsabili.
Ogni pacchetto in package.json è reale e ancora usato.
I record mostrano chi li ha creati e modificati.
Qualcun altro sa di essere responsabile di questa app se me ne vado, e i dati si possono esportare.
Quindici minuti con chi l’ha creata, a schermo condiviso. Stai verificando la configurazione, non leggendo ogni riga di codice.
Dove sta e chi può raggiungerla
Fatti dare l’indirizzo. Aprilo da un dispositivo senza accesso, e da un account personale. Chiedi quale piattaforma la ospita e l’account di chi la paga. Un account personale è la prima cosa da cambiare.
Quali dati contiene
Chiedi cosa entra e da dove arriva. Dati personali dei clienti, dati di pagamento, dati sanitari o password di altri sistemi alzano l’asticella, e possono voler dire che l’app va limitata a una lista di nomi.
Dove sono le chiavi
Elenca ogni servizio esterno che l’app chiama. Ogni chiave dovrebbe stare nelle impostazioni dei segreti dell’hosting, limitata a ciò che serve all’app, e non condivisa con altre app. Cambia ogni chiave che sia mai stata nel codice o in una chat.
Chi può fare cosa
Fai accedere chi l’ha creata come utente normale, o chiedilo a un collega, e prova le azioni da admin. Chiedi a chi l’ha creata di far elencare al suo strumento AI ogni route dell’API e dove verifica il ruolo. Le lacune qui si correggono nel codice dell’app.
Pacchetti e codice
Guardate insieme package.json ed eseguite npm audit. Chiedi che il codice stia in un repository Git aziendale, non solo sul portatile di chi l’ha creata.
Il responsabile, e il giorno in cui se ne va
Scrivi l’app, il suo responsabile, un responsabile di riserva, i suoi dati e i suoi utenti nel tuo elenco delle app. Concordate cosa succede quando il responsabile se ne va. La guida alle app di shadow AI ha una policy di una pagina che puoi copiare.
Le app create con il vibe coding sono sicure da condividere con i colleghi?
Possono esserlo. I problemi comuni riguardano dove sta l’app e come è stata configurata: un link pubblico, nessun vero login, chiavi nel browser, regole del database disattivate. Ognuno si verifica in pochi minuti. Segui la checklist di questa pagina prima di mandare il link.
Qual è il rischio di sicurezza più grande in un’app vibe coded?
Dati che chiunque può raggiungere senza accedere. Di solito succede in uno di due modi: l’app sta su un link pubblico senza login davanti, oppure il database risponde direttamente alle richieste e le sue regole di accesso sono disattivate (la row-level security di Supabase). In entrambi i casi è una questione di configurazione, non di codice scritto male dall’AI.
È sicuro mettere la chiave anon di Supabase nel browser?
La chiave anon o publishable è fatta per stare nel browser, ma solo perché la row-level security limita cosa può raggiungere. Se la row-level security è disattivata su una tabella, chiunque abbia quella chiave può leggerla e modificarla. La chiave segreta o service_role non deve mai stare nel browser: salta ogni regola.
“Accedi con Google” limita un’app alla mia azienda?
Non da solo. Di default può accedere qualsiasi account Google, compreso il Gmail personale. L’impostazione hd di Google restringe solo la scelta dell’account, e Google dice di non farci affidamento. Il server dell’app deve verificare il dominio nel token di accesso verificato a ogni richiesta.
Come verifico se la mia app è indicizzata da Google?
Cerca su Google site: seguito dall’indirizzo della tua app, per esempio site:myapp.lovable.app. Se compaiono pagine, l’app è pubblica e indicizzata. Rendi l’app privata o spostala dietro un login aziendale, poi chiedi a Google di rimuovere le pagine con lo strumento Rimozioni di Search Console, se il dominio è tuo.
Devo dire al mio strumento AI di scrivere codice sicuro?
Sì, ed è meglio dargli istruzioni permanenti che chiederlo una volta. Un file di regole nel progetto (CLAUDE.md, AGENTS.md o una regola di Cursor) dice allo strumento dove vanno le chiavi, come scrivere le query al database e dove verificare i ruoli. npx teamonly init le aggiunge per le app TeamOnly. Poi fai comunque le verifiche da solo: le istruzioni riducono gli errori, non li eliminano.
TeamOnly analizza il codice della mia app in cerca di problemi di sicurezza?
No. TeamOnly mette un login aziendale davanti a ogni app, tiene separati i dati e le chiavi di ogni app, e tiene le app fuori dai motori di ricerca. Non revisiona il tuo codice, non analizza i tuoi pacchetti e non controlla le regole dentro la tua app. Quei punti della checklist restano a te.
Cosa deve verificare l’IT prima di approvare un’app creata con l’AI?
Dove è ospitata e chi può raggiungerla, come è limitato l’accesso, dove sono le chiavi, quali dati contiene, chi ne è responsabile e cosa succede quando quella persona se ne va. La sezione “Per l’IT” di questa pagina è una revisione breve che puoi fare in 15 minuti con chi l’ha creata.
Lascia che sia la piattaforma a chiudere le porte aperte.
Pubblica con un comando e l’app sta dietro il login aziendale, fuori dalle ricerche, con il suo database e i suoi segreti. Provala gratis per 14 giorni, senza carta.