Come proteggere le chiavi API nella tua app

Per proteggere le chiavi API, conservale come segreti o variabili d'ambiente sul tuo hosting, usale solo nel codice lato server e non incollarle mai in chat, nei file di codice, negli screenshot o in un repository Git. Assegna a ogni chiave solo il permesso minimo di cui ha bisogno, imposta limiti di spesa presso il fornitore e, se una chiave viene esposta, sostituiscila (creane una nuova ed elimina la vecchia) invece di limitarti a nasconderla dove è comparsa.

Una chiave API è una password per un servizio. La tua chiave di OpenAI permette a qualcuno di spendere i tuoi soldi in AI; la tua chiave segreta di Stripe permette di emettere rimborsi; la chiave del tuo provider email permette di inviare posta a nome tuo. I builder di app AI sono bravi a collegarle, ma non sempre attenti a dove finiscono, quindi questa guida spiega come proteggerle e come verificarlo.

Chiavi pubbliche e chiavi segrete

Non tutte le chiavi sono segrete. Conoscere la differenza evita di preoccuparsi della chiave sbagliata e di ignorare quella giusta.

Se non sei sicuro del tipo di una chiave, controlla la documentazione del fornitore. Nel dubbio, trattala come segreta.

Passo 1: conserva le chiavi come segreti, non nel codice

Le chiavi vanno nelle impostazioni di variabili d'ambiente o segreti del tuo hosting. Il codice le legge per nome a runtime (per esempio process.env.OPENAI_API_KEY), quindi il valore non compare mai nei tuoi file. Per le basi, vedi cosa sono le variabili d'ambiente e i segreti.

Sposta ogni chiave API fuori dal codice in variabili d'ambiente. Elenca ogni chiave che hai trovato, il file in cui si trovava e il nome della variabile che hai usato. Non mostrarmi i valori.

Poi verifica che non ne sia rimasta nessuna:

Cerca in tutto il progetto, inclusi i file di configurazione e gli eventuali file .env, qualsiasi cosa che sembri una chiave API o una password. Segnala file e riga, non il valore.

Passo 2: usa le chiavi segrete solo sul server

Questa è la regola più importante. Tutto ciò che il browser riceve, un visitatore può leggerlo: il sorgente della pagina e i file JavaScript sono visibili negli strumenti per sviluppatori.

Quindi, se l'app deve chiamare OpenAI, il browser dovrebbe chiamare il tuo server, e il tuo server chiama OpenAI con la chiave. La chiave non lascia mai il server.

La funzione chat chiama OpenAI direttamente dal browser. Sposta quella chiamata in una route API del server che legge OPENAI_API_KEY dall'ambiente. Il browser deve chiamare solo la nostra route. Richiedi l'accesso per la route.

Attenzione a una trappola comune nei framework frontend: le variabili con un prefisso pubblico (VITE_ in Vite, NEXT_PUBLIC_ in Next.js) vengono incluse di proposito nel codice del browser. Una chiave segreta con uno di questi prefissi è esposta, anche se si trova "in una variabile d'ambiente".

Passo 3: verifica che nulla trapeli

Non dare per scontato che abbia funzionato: controlla il sito online:

1. Apri l'app pubblicata in un browser.
2. Apri gli strumenti per sviluppatori, poi la scheda Sources o Network.
3. Cerca nei file i primi caratteri di ogni chiave segreta (per esempio sk_ o sk-).
4. Controlla le richieste di rete che fa l'app. Una richiesta che va direttamente dal browser a un fornitore AI a pagamento è un campanello d'allarme.

Se trovi una chiave segreta, spostala sul server (passo 2) e sostituiscila (passo 6), perché era già pubblica.

Passo 4: limita ciò che ogni chiave può fare

Molti fornitori permettono di limitare una chiave:

• Chiavi con ambito o limitate che possono fare solo ciò che serve alla tua app. Stripe, per esempio, supporta chiavi limitate con permessi specifici.
• Restrizioni per dominio o per IP per le chiavi che devono essere pubbliche, come quelle per le mappe.
• Chiavi separate per app e per ambiente, così una fuga non espone tutto e revocarne una non interrompe le altre.
• Chiavi di test durante lo sviluppo, e chiavi reali solo nell'app pubblicata.

Passo 5: metti un tetto ai danni

Anche una chiave ben protetta può essere usata male tramite la tua app: qualcuno potrebbe, per esempio, lanciare migliaia di volte la tua funzione AI con uno script.

• Imposta limiti di spesa o avvisi presso ogni fornitore a pagamento.
• Richiedi l'accesso per ogni funzione che costa denaro a ogni chiamata.
• Aggiungi un limite di frequenza per utente. Vedi cos'è il rate limiting.

Aggiungi un limite di 30 richieste AI per utente l'ora a /api/chat. Restituisci un messaggio chiaro quando il limite viene raggiunto. Rifiuta le richieste di utenti che non hanno effettuato l'accesso.

Passo 6: sostituisci le chiavi che trapelano

Se una chiave segreta compare dove non dovrebbe (un messaggio in chat, un commit, uno screenshot, un ticket di supporto, il codice del browser), considerala compromessa.

1. Crea una nuova chiave presso il fornitore.
2. Aggiorna il segreto nelle impostazioni della tua app.
3. Ripubblica o rilancia il deploy così che l'app online usi la nuova chiave.
4. Elimina la vecchia chiave presso il fornitore.
5. Controlla i log di utilizzo del fornitore per attività che non riconosci.

Cancellare il messaggio in chat o il commit Git non basta. La cronologia Git conserva le versioni vecchie, e tutto ciò che è pubblico potrebbe essere già stato copiato.

Errori comuni

• Incollare una chiave nel prompt. Ora è nella cronologia della chat. Usa invece un modulo per i segreti.
• Un prefisso pubblico su una variabile segreta. VITE_OPENAI_API_KEY manda la chiave a ogni visitatore.
• Committare un file .env. Assicurati che sia in .gitignore prima del primo push.
• Una sola chiave ovunque. Usa chiavi separate per test e produzione, e per ogni app.
• Nessun limite di spesa. Una chiave esposta o abusata senza tetto può far lievitare la bolletta prima che tu te ne accorga.
• Nascondere invece di sostituire. Una volta esposta, solo una nuova chiave risolve il problema.
• Chiavi negli screenshot. Ritaglia o sfuoca le pagine delle impostazioni prima di condividerle per chiedere aiuto.

Checklist

• Ogni chiave è salvata come segreto o variabile d'ambiente, non nel codice.
• Nessun file .env o chiave è committato su Git.
• Le chiavi segrete sono usate solo nel codice lato server.
• Nessuna variabile segreta usa un prefisso pubblico come VITE_ o NEXT_PUBLIC_.
• Ho cercato nel JavaScript del sito online il prefisso di ogni chiave e non ho trovato nulla.
• Le chiavi sono limitate o con ambito dove il fornitore lo consente.
• Le chiavi di test e quelle reali sono separate.
• Le funzioni a pagamento richiedono l'accesso e hanno limiti per utente.
• Ogni fornitore a pagamento ha un tetto di spesa o un avviso.
• So come sostituire ogni chiave, e ogni chiave mai esposta è stata sostituita.

Proteggere le chiavi su Mythex

Mythex tiene le chiavi fuori dal tuo codice e dalla chat in due modi:

• Scheda di richiesta dei segreti. Quando l'agente ha bisogno di una chiave, mostra una scheda in chat in cui inserisci il valore nei campi del modulo, non nella casella dei messaggi, e viene salvato come segreto del progetto. Vedi Segreti in chat.
• Impostazioni del progetto → Secrets, oppure /secrets in chat, per aggiungere o modificare le chiavi da solo. Vedi Variabili d'ambiente e segreti.

Dopo aver cambiato un segreto di un'app pubblicata, pubblicala di nuovo così l'app online lo recepisce. I progetti esportati non includono i segreti, quindi aggiungili di nuovo dovunque esegui il codice la volta successiva. Se una chiave compare in chat, sostituiscila presso il fornitore.

Per il resto del controllo di sicurezza prima del lancio, segui la checklist di sicurezza per le app create con l'AI. Se stai aggiungendo funzioni AI, come usare le API LLM approfondisce chiavi e costi.

Domande