Sicurezza per app create con l'IA

Cosa significa "sicurezza nel vibe coding"

Gli strumenti di IA (Lovable, Bolt, v0, Cursor, Replit, Windsurf) generano app con un'architettura molto precisa: il browser parla direttamente con il database (Supabase, Firebase) e con i servizi esterni (Stripe, OpenAI, Resend). In mezzo non c'è quasi nessun server tuo. Questo accelera tutto, ma sposta la sicurezza dal tuo codice alla tua configurazione: a proteggerti sono le regole del database, gli header HTTP, la policy CORS e il posto in cui vivono le chiavi, non quanto è pulito il codice dell'interfaccia.

Quei pezzi non arrivano configurati bene di default, e l'IA raramente li imposta se non glielo chiedi. Il suo obiettivo è che l'app funzioni nella demo, e una tabella senza restrizioni o una chiave incollata nel frontend "funzionano" perfettamente. Il risultato sono app che sembrano impeccabili e che espongono dati o chiavi a chiunque sappia dove guardare: non serve essere hacker, basta aprire gli strumenti per sviluppatori del browser.

Per questo "sicurezza nel vibe coding" non significa imparare la crittografia né pagare un audit. Significa conoscere la mezza dozzina di falle che si ripetono in quasi tutte le app create con l'IA, saperle verificare dall'esterno e chiedere alla stessa IA di correggerle con istruzioni precise.

Perché le app create con l'IA falliscono sempre nello stesso punto

C'è uno schema. L'IA ottimizza perché il codice compili e lo schermo mostri dati, non perché uno sconosciuto non possa vederli. Quando una query fallisce per i permessi, la soluzione più corta è togliere il permesso che dà fastidio: disattivare il Row Level Security, mettere una regola che permette tutto o usare la chiave di amministratore. E l'IA sceglie la soluzione più corta.

Il secondo motivo è che copia template. Le variabili con prefisso NEXT_PUBLIC_, VITE_ o NUXT_PUBLIC_ vengono inviate al browser per design, e molti esempi su internet ci mettono chiavi che non dovrebbero mai uscire dal server. Le regole di Firebase in modalità test permettono a chiunque di leggere e scrivere per 30 giorni, e si lanciano app con quella modalità attiva. Gli header di sicurezza non compaiono in quasi nessun tutorial, quindi non compaiono nemmeno nell'app.

Il terzo è che nessuno disegna il modello di minaccia. Chi costruisce con l'IA pensa all'utente che vuole, non al visitatore che apre la scheda Network, copia l'URL dell'API e gli toglie il filtro. Questa guida consiste nel mettersi nei panni di quel visitatore per dieci minuti.

Le sette falle che colpiscono di più le app create con l'IA

Chiavi API nel browser. Quando "colleghi" un servizio, la chiave finisce nel JavaScript del client, dove resta pubblica per sempre: chiunque può leggerla guardando il sorgente e usarla a tue spese (fatture OpenAI, email inviate dal tuo dominio, accesso ai tuoi dati). Le uniche chiavi che possono andare nel client sono quelle progettate per questo, come la chiave anon o publishable di Supabase, la chiave pubblica di Stripe o la configurazione di Firebase, e solo se le regole dietro sono a posto.

Regole del database mancanti o deboli. Senza Row Level Security attivo su ogni tabella Supabase, o con una policy che permette tutto, chiunque legge e scrive i tuoi dati senza fare login, attraverso la stessa API che usa la tua app. In Firebase, le regole in modalità test o con allow read, write: if true fanno lo stesso. È la falla più grave e più frequente, ed è stata l'origine della vulnerabilità CVE-2025-48757 che ha esposto dati di utenti in app fatte con Lovable.

CORS permissivo. Un'API che risponde con Access-Control-Allow-Origin riflettendo qualsiasi origine e che in più permette le credenziali lascia che un sito malevolo faccia richieste a nome dei tuoi utenti e ne legga le risposte. L'asterisco su un'API pubblica senza cookie è accettabile; riflettere l'origine con credenziali, mai.

Header di sicurezza assenti. Senza Content-Security-Policy, Strict-Transport-Security, X-Frame-Options (o frame-ancestors), X-Content-Type-Options, Referrer-Policy e Permissions-Policy, la tua app è esposta a clickjacking, injection di script, downgrade a HTTP e fughe di URL interni. Si configurano sul server o sull'hosting (Vercel, Netlify, Cloudflare) in dieci righe.

File sensibili accessibili. Un .env pubblicato per errore, una cartella .git esposta, source map che permettono di ricostruire il codice sorgente completo, backup del database o pannelli di amministrazione senza autenticazione. Sono facili da trovare perché gli attaccanti li cercano in automatico su ogni nuovo dominio che compare.

Sessioni e cookie configurati male. Cookie di sessione senza gli attributi Secure, HttpOnly e SameSite, token salvati nel localStorage alla portata di qualsiasi script, o sessioni che non scadono mai. Un piccolo XSS diventa furto di account quando il cookie è leggibile da JavaScript.

Endpoint che si fidano del client. Route API che accettano l'identificativo dell'utente, il prezzo o il ruolo dal corpo della richiesta senza verificarlo sul server. Se l'interfaccia nasconde il pulsante di amministratore ma la route continua a rispondere a chiunque, il pulsante non protegge nulla.

Cosa controllare a seconda del tuo stack

Lovable, Bolt o v0 con Supabase. Controlla che tutte le tabelle abbiano RLS attivo e policy per operazione (select, insert, update, delete) basate su auth.uid(); che la chiave service_role non sia in nessuna variabile pubblica; che i bucket privati dello Storage abbiano policy; e che viste e funzioni RPC non bypassino le policy. La dashboard di Supabase include un Security Advisor che elenca le cose più gravi.

Cursor, Windsurf o Replit con Next.js, Nuxt o Express pubblicato su Vercel. Verifica quali variabili d'ambiente hanno prefisso pubblico, che le route API validino la sessione a ogni richiesta e non solo nell'interfaccia, che gli header di sicurezza siano definiti (vercel.json, next.config o nuxt.config) e che non si pubblichino source map in produzione.

Firebase. Sostituisci le regole in modalità test con regole basate su request.auth, sia in Firestore che nello Storage; attiva App Check perché solo la tua app possa usare i tuoi servizi; e verifica che le Cloud Functions che fanno qualcosa di sensibile controllino il token dell'utente prima di agire.

Se l'app "sembra a posto" non significa che sia sicura

Nascondere un pulsante nell'interfaccia non protegge nulla: la richiesta resta un URL pubblico che chiunque può chiamare direttamente dalla console del browser o con curl. La vera sicurezza sta sul server e nel database, non in ciò che vede l'utente. Ecco perché controllare dall'esterno —come farebbe un attaccante— è l'unico modo per sapere cosa è davvero esposto.

Non basta nemmeno che il lucchetto HTTPS sia verde. HTTPS cifra il tragitto tra il browser e il tuo server; non dice nulla sul fatto che il server consegni dati a chi non dovrebbe. Un'app con certificato perfetto e una tabella senza RLS è un'app con una fuga perfettamente cifrata.

Come verificarlo da solo in dieci minuti

Uno: apri il tuo sito e guarda il sorgente (clic destro, visualizza sorgente pagina). Cerca key, secret, sk_, service_role e i nomi dei servizi che usi. Tutto ciò che compare lì è pubblico.

Due: con l'app aperta, vai nella scheda Network degli strumenti per sviluppatori, individua una richiesta al tuo database o alla tua API, copia l'URL e aprilo in una finestra in incognito. Se restituisce dati senza sessione, quell'endpoint è aperto. Da loggato, togli il filtro utente dall'URL: se restituisce righe di altri, le policy sono sbagliate.

Tre: chiedi gli header del tuo dominio con curl -I https://tuodominio.com e verifica se compaiono Content-Security-Policy, Strict-Transport-Security e X-Frame-Options o frame-ancestors. Se ne manca uno, non è configurato.

Quattro: prova ad aprire /.env, /.git/config, /config.json e un file .js.map del tuo bundle. Tutti devono restituire 404 o 403.

Cinque: crea due account di prova e verifica che nessuno veda, modifichi o cancelli i dati dell'altro, file caricati compresi. È il test più noioso e quello che trova più falle.

Come verificarlo in 30 secondi

Scanaris automatizza quei test e qualche altro. Analizza il tuo sito già pubblicato in sola lettura: non tocca il tuo codice, non inietta nulla né prova a sfruttare nulla; guarda ciò che è già pubblico, come farebbe chiunque dall'esterno. Controlla header, cookie, certificato TLS, CORS, segreti nel JavaScript, file sensibili, tecnologie con versioni note, le regole di Supabase se gli dai una connessione in sola lettura, e inoltre come ti vede Google e come ti leggono le IA.

Ogni risultato arriva ordinato per impatto (prima il critico), spiegato in linguaggio normale e con un prompt di correzione pronto da incollare in Lovable, Cursor o lo strumento che usi. Incolla il tuo URL, aspetta mezzo minuto e saprai se puoi condividere la tua app a cuor leggero.

Cosa tenere d'occhio dopo il lancio

La sicurezza non è uno stato, è un'abitudine. Ogni tabella nuova nasce senza RLS, ogni funzione nuova può mettere una chiave nel posto sbagliato e ogni dipendenza invecchia. Programma una nuova scansione periodica e guarda le differenze, non tutto il report: l'importante è cosa si è aperto dall'ultima volta.

Tieni d'occhio anche ciò che non dipende dal codice: che certificato e dominio non scadano, che il sito risponda, e che nel browser dei tuoi utenti non compaiano script che non hai messo tu. E quando correggi qualcosa, ricontrollalo dall'esterno: la correzione conta quando lo scanner smette di vederla, non quando l'IA dice che è fatto.

Approfondisci per il tuo stack

Controlli di sicurezza chiave

Guide correlate

Domande frequenti