Chiave API esposta nel frontend: come accorgersene e rimediare

Se temi di avere una chiave API esposta nel frontend della tua app creata con l'AI, sei nel posto giusto. La risposta breve è questa: se una chiave segreta finisce nel codice che gira nel browser, va considerata pubblica. Va revocata, sostituita con una nuova e usata solo da un server. Qui sotto ti spieghiamo come capire se è il tuo caso e cosa fare, in ordine.

Cos'è una chiave API e cosa vuol dire «esposta»

Una API è il modo in cui la tua app parla con un servizio esterno: OpenAI per generare testi, Stripe per i pagamenti, un servizio di invio email. La chiave API è la password che dice a quel servizio «sono io, addebita a me».

Il frontend è la parte dell'app che viene scaricata e gira nel browser di chi visita il sito. Il backend è la parte che gira su un server che controlli tu. Pensa al frontend come a una vetrina: tutto quello che ci metti dentro si vede da fuori, anche se è in fondo allo scaffale.

Una chiave è «esposta» quando si trova nel codice del frontend o in un file pubblico. Chiunque apra il sito, con due clic, può leggerla e usarla a tuo nome.

Non tutte le chiavi sono segrete

Prima di allarmarti, verifica che tipo di chiave hai. Alcune sono progettate per stare nel browser, altre no.

La regola pratica: se il fornitore la chiama secret, private o server key, oppure se chi la possiede può spendere soldi a tuo nome o leggere i dati di tutti, non deve stare nel browser.

Perché succede così spesso con le app fatte con l'AI

Gli strumenti come Lovable, Bolt, v0 o Cursor puntano a far funzionare le cose in fretta. Quando chiedi «collega OpenAI», la strada più corta è mettere la chiamata direttamente nella pagina, con la chiave incollata accanto. Funziona subito, ed è proprio questo il problema.

Le cause più comuni sono queste:

• Chiave scritta nel codice: la chiave è stata incollata in chat e l'AI l'ha inserita in un componente dell'interfaccia.
• Prefisso sbagliato nelle variabili d'ambiente: le variabili che iniziano con VITE_ o NEXT_PUBLIC_ vengono copiate nel codice inviato al browser. Se ci metti una chiave segreta, la pubblichi. Ne parliamo meglio nella guida sulle variabili d'ambiente e le chiavi API online.
• File .env su GitHub: il file con le chiavi è finito in un repository pubblico.
• Chiave di servizio di Supabase usata nel browser: qualcosa non funzionava con la chiave pubblica e la «soluzione» è stata usare quella che salta tutti i controlli. Di solito il vero problema erano le regole di accesso, come spieghiamo nell'articolo sulla RLS di Supabase e i dati esposti.

Come capire se è il tuo caso

Puoi fare una prima verifica da solo, senza toccare nulla.

1. Apri il sito pubblicato in Chrome o in un browser simile. Premi F12 oppure fai clic destro e scegli «Ispeziona».
2. Cerca in tutti i file caricati. Nella scheda Sources (o Origini) usa la ricerca globale: Ctrl+Shift+F su Windows, Cmd+Option+F su Mac. Cerca stringhe come sk-, sk_live, service_role, sb_secret, secret.
3. Guarda le richieste di rete. Nella scheda Network (o Rete) usa la funzione dell'app che chiama il servizio esterno. Se vedi una richiesta che parte dal browser direttamente verso il fornitore (per esempio verso l'indirizzo delle API di OpenAI), la chiave sta viaggiando con quella richiesta.
4. Controlla il repository, se hai il codice su GitHub. Verifica che il file .env non sia mai stato caricato e che nessuna variabile pubblica contenga una chiave segreta.
5. Osserva i segnali indiretti: consumi anomali nella dashboard del fornitore, email che avvisano di una chiave trovata online. Alcuni fornitori ricevono segnalazioni automatiche quando una loro chiave compare in un repository pubblico, e possono avvisarti o disattivarla.

Se trovi una chiave segreta in uno di questi punti, considerala compromessa. Non importa da quanto tempo è lì.

Cosa fare se la chiave è esposta

Ecco i passi in ordine. Non serve farsi prendere dal panico, ma conviene agire in giornata.

1. Valuta l'urgenza. Se vedi consumi strani o accessi sospetti, revoca subito la chiave dal pannello del fornitore, anche se l'app smetterà di funzionare per un po'. Meglio una funzione ferma che un conto che cresce.
2. Sposta la chiamata sul server. Prima di creare una chiave nuova, togli il motivo per cui la vecchia era esposta. Altrimenti anche la nuova finirà nello stesso posto. La chiamata al servizio va fatta da una funzione server: una Edge Function di Supabase, una route API in Next.js, una funzione serverless del tuo hosting. Il browser chiede alla funzione, la funzione usa la chiave. È come al ristorante: il cliente ordina al cameriere, non entra in cucina.
3. Crea una chiave nuova e salvala come segreto. Mettila nelle impostazioni dei segreti della piattaforma (per esempio la sezione Secrets su Lovable, le variabili d'ambiente su Vercel o Netlify, i segreti delle funzioni su Supabase), senza prefissi pubblici.
4. Revoca o elimina la vecchia chiave. Controlla prima che tutte le parti dell'app usino quella nuova.
5. Controlla i consumi e i dati. Guarda l'utilizzo degli ultimi giorni. Se la chiave dava accesso a dati di utenti, verifica cosa poteva essere letto o modificato.
6. Riduci i danni futuri. Dove possibile, imposta limiti di spesa, usa chiavi con permessi ridotti (Stripe, per esempio, offre chiavi con accesso limitato), limita le chiavi del browser al tuo dominio e richiedi il login per usare le funzioni che costano.

Se lavori con un assistente AI, puoi chiedergli lo spostamento in modo esplicito:

Sposta tutte le chiamate a OpenAI in una funzione lato server.
La chiave deve essere letta da una variabile d'ambiente segreta,
senza prefisso VITE_ o NEXT_PUBLIC_, e non deve mai comparire
nel codice del frontend. La funzione deve rispondere solo
a utenti autenticati.

Poi ricontrolla con il punto 2 della sezione precedente: la chiave non deve più comparire nei file del sito.

Perché cancellarla dal codice non basta

Togliere la chiave dal file e ripubblicare è il primo istinto, ma non risolve. Chi l'ha già vista ne ha una copia. In più, se usi Git, la chiave resta nella cronologia del progetto: chiunque abbia accesso al repository può tornare alle versioni precedenti. Riscrivere la cronologia è possibile, ma è secondario. Il rimedio vero è sempre la revoca.

Come evitare che succeda di nuovo

Qualche abitudine semplice riduce molto il rischio:

• Non incollare chiavi segrete nella chat dell'AI. Alcuni strumenti, come Lovable, riconoscono le chiavi incollate e propongono di salvarle tra i segreti: segui quella strada.
• Tieni il file .env fuori dal repository (deve essere elencato nel file .gitignore).
• Prima di ogni lancio, ripeti la ricerca nei file del sito pubblicato.
• Quando aggiungi un servizio esterno, chiediti sempre: questa chiamata parte dal browser o da un server? Ne parliamo anche nella guida per integrare servizi esterni nell'app.

Le chiavi sono solo uno dei punti da verificare prima di andare online. Se vuoi una visione d'insieme, trovi tutto nella checklist di sicurezza per app create con l'AI.

Quando conviene farti aiutare

Molti casi si risolvono da soli seguendo i passi sopra. Ha senso chiedere aiuto se la chiave è già stata usata da qualcun altro, se l'app gestisce pagamenti o dati personali, oppure se spostando la chiamata sul server qualcosa si rompe e l'AI continua a rimettere la chiave dove non deve.

Di solito controlliamo dove passano tutte le chiavi, spostiamo le chiamate sensibili lato server e verifichiamo che le regole di accesso al database reggano. Se vuoi capire da dove partire, prenota una call gratuita: in 20 minuti guardiamo insieme la situazione.