Un sito che utilizza un CRM, un servizio di pagamento, un'API di cartografia o uno strumento di invio email gestisce quasi sempre chiavi di accesso, chiamate anche segreti, che permettono a questi servizi esterni di identificare e autorizzare le richieste inviate dal sito. Queste chiavi funzionano come password, con una differenza importante: vengono spesso copiate, condivise, e integrate nel codice senza che nessuno si interroghi sul loro reale livello di protezione.

L'errore più frequente: la chiave scritta direttamente nel codice

Su uno sviluppo PHP su misura, resta comune trovare una chiave API scritta direttamente in un file di configurazione versionato insieme al resto del codice sorgente. Il problema emerge non appena questo codice viene condiviso, sia tramite un repository Git privato accessibile a un fornitore esterno, sia tramite un'esportazione verso un nuovo sviluppatore, o peggio, un repository che diventa accidentalmente pubblico. Una volta che una chiave è circolata nella cronologia delle versioni, rimuoverla dal codice attuale non basta: resta leggibile nelle versioni precedenti finché non viene revocata e sostituita con una nuova.

La buona pratica di base: le variabili d'ambiente

La soluzione standard consiste nel togliere le chiavi dal codice sorgente e memorizzarle in variabili d'ambiente, generalmente tramite un file chiamato .env, che non viene mai incluso nel repository di codice grazie a un file .gitignore che lo esclude esplicitamente. Il codice applicativo legge quindi la chiave da questa variabile al momento dell'esecuzione, senza mai scriverla in chiaro in un file tracciato dal controllo di versione. Questo approccio resta adeguato per uno sviluppo locale o un sito di dimensioni modeste, a condizione di non trasmettere mai questo file via email o messaggistica istantanea, canali che lasciano tracce difficili da cancellare completamente.

Cosa non protegge questo file

Un file .env correttamente escluso dal repository di codice resta comunque presente in chiaro sul server di produzione, il che significa che un accesso non autorizzato al server, ad esempio tramite una falla in un plugin WordPress o una password FTP compromessa, espone direttamente tutte le chiavi che contiene. Per un sito con requisiti di sicurezza più elevati, in particolare quando più persone o fornitori intervengono sull'infrastruttura, un gestore di segreti dedicato, come quelli offerti dai principali fornitori cloud, permette una memorizzazione cifrata con un controllo preciso di chi può consultare quale chiave, andando oltre ciò che un semplice file locale può offrire.

La trappola del frontend e del codice visibile dal browser

Una chiave integrata in codice JavaScript eseguito lato browser, anche in un file compilato o minificato, resta tecnicamente accessibile a chiunque ispezioni il codice sorgente della pagina. È un errore frequente quando un'integrazione di terze parti viene aggiunta rapidamente senza far transitare la richiesta attraverso il server del sito. La soluzione consiste nel far passare queste chiamate attraverso un punto d'ingresso lato server, che conserva la chiave segreta e trasmette al browser solo il risultato necessario, mai la chiave stessa.

Limitare ogni chiave al suo uso specifico

La maggior parte dei servizi permette di limitare una chiave API a un dominio preciso, un intervallo di indirizzi IP, o un insieme di azioni autorizzate, una funzionalità spesso ignorata per semplicità al momento della creazione della chiave. Questa restrizione non costa nulla da implementare e riduce fortemente l'impatto di un'eventuale fuga, poiché una chiave limitata a nikaia.net non può essere riutilizzata da un altro dominio anche se scoperta.

Rinnovare le chiavi, non solo proteggerle

Una chiave creata al lancio di un progetto e mai rinnovata da allora resta un rischio che si accumula nel tempo, in particolare quando più fornitori o dipendenti vi hanno avuto accesso nel corso degli anni senza che l'elenco delle persone coinvolte venga tenuto aggiornato. Un rinnovo periodico, anche semplice, limita la finestra di sfruttamento di una chiave che fosse trapelata senza che nessuno se ne accorgesse.

Punti da verificare prima della pubblicazione: confermare che la descrizione del funzionamento dei file .env e della loro esclusione tramite .gitignore resti conforme alle pratiche standard di sviluppo PHP alla data di pubblicazione, e verificare che gli esempi di gestori di segreti citati restino soluzioni comunemente utilizzate sul mercato.