Sicurezza delle chiavi API email: permessi, rotazione e dove conservarle

Una chiave API email è una stringa breve con molto potere. Chi la possiede può inviare email dal tuo dominio, a chiunque, a tuo nome. Le chiavi trapelate sono uno dei modi più comuni in cui le campagne di phishing finiscono per partire dall’infrastruttura di aziende legittime.

La buona notizia: poche abitudini rendono improbabile una fuga e ne limitano i danni se accade comunque. Questa guida le illustra, usando i controlli che Inbixio offre per ogni chiave.

Cosa può fare una chiave Inbixio

Ogni chiave che crei in API Keys → Create Api Key (chiavi API → crea chiave API) ha tre impostazioni:

• Name (nome), per la tua organizzazione interna, ad esempio prod-auth-service.
• Server Access (accesso ai server): All Server (tutti i server; invia tramite il primo server SMTP che hai collegato) oppure Selected Server (server selezionato; esattamente quello che scegli).
• Permissions (permessi): Send, Read e Manage (invio, lettura e gestione). Al momento l’API ha un solo endpoint, l’invio di email, quindi Send è il permesso di cui i tuoi servizi hanno bisogno.

Le chiavi hanno la forma ibx_ seguito da 32 caratteri esadecimali. Il prefisso le rende facili da riconoscere, anche per gli strumenti di secret scanning.

Regola 1: una chiave per servizio e ambiente

Non condividere un’unica chiave in tutta l’azienda. Crea una chiave separata per ogni servizio e per ogni ambiente:

Chiavi separate significano:

• Una fuga resta circoscritta. Revocare prod-billing non blocca le email di accesso.
• Ogni servizio invia dall’indirizzo giusto. Una chiave associata al server billing@ invia da billing@, non dal primo server che hai collegato. Se elimini un server associato, la chiave torna al tuo primo server, quindi riassocia le chiavi quando rimuovi dei server.
• La rotazione è indolore. Puoi rinnovare la chiave di un servizio senza toccare le altre.

Regola 2: concedi il permesso minimo

Un backend che invia email ha bisogno di Send e di nient’altro, quindi lascia deselezionati Read e Manage. Meno una chiave può fare, meno costa una fuga.

Regola 3: le chiavi stanno sui server, mai nei client

Tutto ciò che viene distribuito a un browser o a un’app mobile può essere estratto, minificato o no. Questo include:

• bundle JavaScript (React, Vue, componenti client di Next.js),
• variabili d’ambiente con prefisso per il browser, come NEXT_PUBLIC_, VITE_ o REACT_APP_,
• binari delle app iOS e Android.

Se un’azione dell’utente nel frontend deve attivare un’email, chiama un endpoint del tuo backend. Il backend verifica che l’utente sia autorizzato, applica i limiti di frequenza e solo allora chiama Inbixio con la chiave che conserva nel proprio ambiente.

// ✅ Browser → your API → Inbixio
await fetch('/api/invite', { method: 'POST', body: JSON.stringify({ email }) });

// ❌ Never do this in frontend code
fetch('https://backend.inbixio.com/api/send-email/', {
  headers: { 'X-API-Key': 'ibx_…' }, // visible to every visitor
});

Regola 4: conserva le chiavi come password

• Metti le chiavi in un secrets manager (AWS Secrets Manager, Google Secret Manager, Doppler, 1Password, Vault) o nelle variabili d’ambiente cifrate della tua piattaforma.
• Non fare mai commit delle chiavi. Aggiungi .env a .gitignore e attiva il secret scanning sui tuoi repository; la push protection di GitHub blocca molte fughe prima che avvengano.
• Tieni le chiavi fuori dai log. Se registri le richieste in uscita, rimuovi prima l’header X-API-Key.
• Non incollare le chiavi in ticket, chat o screenshot. Condividi l’accesso al segreto, non il suo valore.

Regola 5: ruota con regolarità e subito in caso di dubbio

Inbixio può rinnovare una chiave: fai clic sull’icona di aggiornamento accanto alla chiave nella pagina API Keys. Il rinnovo genera un nuovo valore con lo stesso nome, lo stesso accesso ai server e gli stessi permessi, e il vecchio valore smette subito di funzionare. Per ruotare una chiave di produzione senza invii falliti:

1. Crea una seconda chiave con le stesse impostazioni (ad esempio prod-auth-2).
2. Distribuisci la nuova chiave al servizio e verifica che le sue richieste restituiscano 200, ad esempio nei log della tua applicazione.
3. Elimina la vecchia chiave.

Usa l’icona di aggiornamento quando la rapidità conta più di un passaggio senza interruzioni, ad esempio subito dopo una fuga. Ruota le chiavi ordinarie ogni pochi mesi e ogni volta che una persona con accesso lascia il team.

Se una chiave trapela

Trattalo come un incidente, ma gestibile:

1. Rinnova (icona di aggiornamento) o elimina subito la chiave. In questo modo il vecchio valore non può più essere usato.
2. Controlla i log della dashboard alla ricerca di attività insolite: chiamate in orari strani o un picco di volume. Il log mostra quando sono state effettuate le chiamate, non quale chiave le ha effettuate, quindi confrontalo con i log dei tuoi servizi.
3. Controlla il tuo provider di posta per bounce o segnalazioni di spam causati da messaggi che non hai inviato tu.
4. Scopri come è trapelata, che si tratti di un commit, di una riga di log o di un bundle frontend, e chiudi quella falla.
5. Avvisa gli utenti coinvolti se sono stati inviati messaggi a tuo nome, così sanno di doverli ignorare.

Checklist rapida

• Una chiave per servizio e ambiente, con nomi chiari
• Chiavi associate al server (indirizzo mittente) che ogni servizio deve usare
• Solo il permesso Send sui servizi che inviano
• Nessuna chiave nel codice frontend, nelle app mobile o nei repository
• Chiavi conservate in un secrets manager e rimosse dai log
• Una data di rotazione in calendario e un piano in caso di fuga

La sicurezza è anche ciò che ti tiene fuori dallo spam: i messaggi inviati con una chiave compromessa danneggiano la reputazione del tuo dominio. Abbina questa checklist a SPF, DKIM e DMARC per avere il quadro completo.