Come Conservare le Chiavi API in Modo Sicuro in Qualsiasi App Web AI

La fuga di una chiave API è uno dei modi più rapidi per accumulare un conto cloud a cinque cifre o per consegnare agli attaccanti l'accesso ai dati dei tuoi utenti. Accade più spesso di quanto si pensi — e quasi sempre inizia con una singola riga come const apiKey = "sk-live-abc123" inserita in una codebase. Questo articolo spiega esattamente come avviene l'esposizione dei segreti, come appare l'architettura corretta e i passi concreti che puoi compiere adesso per conservare le chiavi API in modo sicuro in qualsiasi app web.

Il modo più sicuro per conservare le chiavi API in un'applicazione web è tenerle esclusivamente lato server — cifrate a riposo in un secrets manager, iniettate nell'ambiente di runtime all'avvio, e mai incluse nel JavaScript lato client. Le chiavi non devono mai comparire nel codice sorgente, nella cronologia del version control, nei log di build o in qualsiasi risposta HTTP che raggiunga un browser.

Quali Sono i Rischi dell'Hardcoding delle Chiavi API nel Codice Sorgente?

Inserire una chiave direttamente in un file JavaScript o TypeScript crea almeno tre distinte superfici di attacco:

1. Esposizione in repository pubblici. Il bot di secret-scanning di GitHub individua alcune chiavi, ma lo fa dopo il push. Nei minuti tra il push e il rilevamento, bot automatici scansionano continuamente i nuovi commit. GitGuardian ha riportato nel 2023 che oltre 10 milioni di segreti sono stati rilevati in commit pubblici — un aumento del 67% anno su anno.
2. Inclusione nel bundle client. Anche se il tuo repo è privato, un bundler come webpack o il compilatore di Next.js inserirà qualsiasi costante importata nel JavaScript che viene inviato al browser. Chiunque può aprire Chrome DevTools → Sources e cercare il prefisso della tua chiave (sk-, SG., pk_live_).
3. Fuga nei log di build. I sistemi CI spesso stampano i valori delle variabili d'ambiente durante i passaggi di installazione o build. Una policy di conservazione dei log mal configurata può rendere quei log leggibili a chiunque abbia accesso al repo.

"Ci sono voluti meno di 30 secondi dopo che ho fatto il push su GitHub perché un bot automatico trovasse la mia chiave AWS e iniziasse a creare istanze GPU. Il conto ha raggiunto 8.000 dollari prima che me ne accorgessi." — un pattern comunemente riportato nei post-mortem degli sviluppatori su Hacker News.

La conclusione è semplice: una chiave che entra mai nel bundle client o in un log pubblico è già compromessa, anche se la ruoti immediatamente.

Le Chiavi API Devono Essere Conservate nelle Variabili d'Ambiente?

Le variabili d'ambiente sono il passo standard rispetto all'hardcoding, ma nei framework come Next.js presentano un'importante avvertenza: solo le variabili con prefisso NEXT_PUBLIC_ sono intenzionalmente esposte al browser. Qualsiasi variabile senza quel prefisso rimane sul server — ma solo se vi accedi esclusivamente all'interno di getServerSideProps, Route Handler, API route o server component.

La trappola in cui cadono molti sviluppatori è quella di referenziare una variabile d'ambiente non pubblica all'interno di un componente che Next.js renderizza staticamente a build-time. Il bundler vede il riferimento, risolve il valore e lo incorpora nell'HTML di output. A quel punto il nome della variabile offriva una falsa sicurezza.

La distinzione fondamentale è tra build-time e iniezione a runtime:

• Build-time — i valori vengono incorporati nel bundle durante next build. Veloce, ma il segreto è congelato nell'artefatto.
• Iniezione a runtime — i valori vengono letti dall'ambiente di processo del server dopo l'avvio del container, senza mai toccare il bundle. Questo è il modello corretto per i segreti.

L'iniezione a runtime significa che anche se qualcuno ottiene il tuo artefatto di build, la chiave non vi è contenuta. Il segreto risiede solo nell'ambiente di esecuzione.

Come Si Usa un Secrets Manager per Conservare le Chiavi API?

Un secrets manager è un servizio dedicato che conserva le credenziali cifrate a riposo, controlla l'accesso tramite policy in stile IAM e consegna i valori alla tua applicazione a runtime senza esporli in transito. AWS Secrets Manager e HashiCorp Vault sono le due scelte più comuni.

Il flusso tipico è il seguente:

1. Salvi il segreto (ad es., la tua chiave segreta Stripe) nel secrets manager tramite la sua UI o CLI.
2. Il segreto viene cifrato usando una chiave KMS che solo il ruolo IAM della tua applicazione può decifrare.
3. Quando il tuo server si avvia, chiama l'API del secrets manager, decifra il valore e lo carica in process.env — solo in memoria.
4. Il tuo codice legge process.env.STRIPE_SECRET_KEY a runtime. Il valore non era mai nel codice sorgente, mai in un artefatto di build, mai in un log.

Questa architettura significa che la rotazione di una chiave richiede solo l'aggiornamento del valore nel secrets manager; nessuna modifica al codice, nessun redeploy del bundle.

Come Funziona il Vault per Segreti Cifrati di FloopFloop

FloopFloop include un vault per segreti integrato basato su AWS KMS. Quando aggiungi una chiave API di terze parti — ad esempio una chiave segreta Stripe o una chiave API SendGrid — tramite l'UI delle impostazioni del progetto sulla piattaforma, FloopFloop la cifra immediatamente a riposo. La chiave viene iniettata nell'ambiente di runtime Lambda della tua app all'avvio e non viene mai scritta nel codice sorgente generato, mai stampata nei log di build e mai restituita nelle risposte CloudFront.

Questo elimina completamente la classe più comune di errori di fuga delle chiavi. Non devi configurare ruoli IAM, schedule di rotazione o policy delle chiavi KMS da solo — la piattaforma gestisce quel livello.

Aggiungere una Chiave API di Terze Parti: Passo dopo Passo

1. Apri il tuo progetto in FloopFloop e naviga nel pannello delle impostazioni del progetto.
2. Trova la sezione Secrets e clicca su Add Secret.
3. Inserisci il nome della variabile (ad es., STRIPE_SECRET_KEY) e incolla il valore della chiave.
4. Salva. FloopFloop cifra il valore con KMS e lo associa al tuo progetto.
5. Nel codice lato server della tua app, referenzialo come process.env.STRIPE_SECRET_KEY. È disponibile a runtime nelle funzioni Lambda e nei server component — mai nei bundle client.
6. Il deployment continuo di FloopFloop recepisce il nuovo segreto al prossimo passaggio di generazione; non è necessario alcun passaggio manuale di redeploy.

Il valore del tuo segreto viene cifrato prima di lasciare la tua sessione browser e non viene mai conservato in chiaro in alcun punto dell'infrastruttura di FloopFloop.

Come Si Impedisce che le Chiavi API Siano Esposte nel Codice Lato Client?

Per le chiamate agli LLM in particolare, il pattern più robusto è un AI Gateway — un proxy lato server che detiene le credenziali API e inoltra le richieste dal tuo frontend. Il codice del browser chiama /api/chat; il tuo server chiama OpenAI. La chiave non raggiunge mai il client.

FloopFloop va oltre con un AI Gateway integrato. Le app generate sulla piattaforma possono chiamare gli LLM supportati tramite il gateway senza che l'utente debba fornire alcuna chiave API personale di OpenAI, Anthropic o altri provider di modelli. La piattaforma gestisce centralmente il routing dei modelli, i limiti di frequenza e i crediti di utilizzo. Ciò significa che il percorso di integrazione degli LLM è a zero credenziali per lo sviluppatore — semplicemente non c'è alcuna chiave da far trapelare.

Le Chiavi API Possono Essere Conservate in Modo Sicuro in un Database?

Sì, a determinate condizioni. Conservare i segreti in un database è valido se:

• La colonna è cifrata a livello applicativo (non solo con la cifratura del disco a riposo, che non protegge dagli attacchi SQL injection).
• L'accesso alla chiave di decifratura è strettamente controllato (idealmente tramite una chiave gestita da KMS, non una chiave hardcoded).
• Il segreto viene recuperato lato server e mantenuto in memoria solo per la durata della richiesta — mai serializzato in una risposta JSON.

Un database non è adatto come archivio principale di segreti se la stringa di connessione al database stesso è conservata in modo non sicuro. Si finisce in una dipendenza circolare. Un secrets manager dedicato (o una piattaforma che ne fornisce uno) evita quella trappola.

Checklist di Verifica della Sicurezza per la Tua App Distribuita

Dopo il deployment, esegui questi controlli sull'URL live <progetto>.floop.tech (o sul tuo dominio personalizzato):

• Visualizza il sorgente della pagina — cerca i prefissi delle tue chiavi (sk-, pk_live_, SG., Bearer ). Nessuno deve comparire.
• DevTools → scheda Network — ispeziona le risposte API. I valori segreti non devono comparire in alcun payload JSON restituito al browser.
• DevTools → Sources — cerca nei bundle JS caricati i primi 8 caratteri di ciascuna chiave.
• Log di build — conferma che nessun console.log, output di debug o stack trace di errore stampi un valore segreto.
• Intestazioni delle risposte HTTP — i segreti non devono comparire in Set-Cookie, intestazioni personalizzate o pagine di errore.
• Ruota immediatamente qualsiasi chiave che non supera un controllo — considerala già nota agli avversari.

Conclusioni

Conservare le chiavi API in modo sicuro in un'app web si riduce a una regola: i segreti appartengono al server, cifrati a riposo, iniettati a runtime e mai in alcun artefatto che raggiunga un browser. Usa le variabili d'ambiente correttamente, preferisci un secrets manager basato su KMS ai file .env e considera un AI Gateway per rimuovere completamente le credenziali degli LLM dal tuo progetto. Se stai sviluppando su FloopFloop, il vault per segreti cifrati e l'AI Gateway integrato gestiscono entrambe le problematiche automaticamente, così puoi concentrarti su ciò che la tua app fa davvero.