Che cos'è la sicurezza delle chiavi API?

Una chiave API è una stringa unica che identifica l’app che chiama un’API; la sicurezza delle chiavi API consiste nel limitarne l’ambito e proteggerla. Prima la precisione, perché la maggior parte delle definizioni la confonde: una chiave identifica l’applicazione, offre soltanto un’autenticazione debole (è una credenziale bearer – chi la detiene, la incarna) e porta un’autorizzazione grossolana (l’ambito che le è stato attaccato alla creazione). Le persone vengono autenticate dai token; le app vengono identificate dalle chiavi – e nessuna RFC definisce la chiave API. È una convenzione, ed è esattamente per questo che la sua sicurezza dipende dalla configurazione di chi la usa, non dalla garanzia di uno standard.

Punti chiave

La richiesta, e i due tipi di chiave

GET /v1/search?q=espresso HTTP/1.1
Host: api.example.com
X-Api-Key: pk_live_7f2c…      ← in un HEADER – gli URL finiscono nei log,
                                 nella cronologia e nei referrer

Due specie diverse condividono un solo nome:
chiave pubblicabile  spedita nei bundle web/mobile · identifica l'app,
                     misura l'uso · progettata sapendo che SARÀ estratta
chiave segreta       solo lato server · credenziale bearer tipo password ·
                     chi la detiene passa per il titolare

Il modello pubblicabile in pratica – chiavi che vengono spedite perché la sicurezza vive altrove:

// JavaScript / Node.js — Back4app JS SDK
// Publishable keys: safe to ship BECAUSE authorization lives server-side
Parse.initialize(APP_ID, JS_KEY); // both ship in your bundle — by design
Parse.serverURL = 'https://parseapi.back4app.com';
// What protects data isn't key secrecy — it's CLPs + ACLs checked per request

// The one key that never ships: the Master Key bypasses every ACL and CLP.
// Server-only (Cloud Code / trusted backend), read from env or secret manager.

// Flutter / Dart — Back4app Flutter SDK
// Publishable keys: safe to ship BECAUSE authorization lives server-side
await Parse().initialize(
  appId, // ships in the app — by design
  'https://parseapi.back4app.com',
  clientKey: clientKey, // publishable, extractable, NOT a secret
);
// What protects data isn't key secrecy — it's CLPs + ACLs checked per request
// The Master Key bypasses every ACL and CLP: server-only, never in the app.

// iOS / Swift — Back4app Swift SDK
// Publishable keys: safe to ship BECAUSE authorization lives server-side
ParseSwift.initialize(
    applicationId: appId,  // ships in the IPA — by design
    clientKey: clientKey,  // publishable, extractable, NOT a secret
    serverURL: URL(string: "https://parseapi.back4app.com")!
)
// What protects data isn't key secrecy — it's CLPs + ACLs checked per request
// The Master Key bypasses every ACL and CLP: server-only, never in the app.

// Android / Kotlin — Back4app Android SDK
// Publishable keys: safe to ship BECAUSE authorization lives server-side
Parse.initialize(
    Parse.Configuration.Builder(context)
        .applicationId(APP_ID) // ships in the APK — by design
        .clientKey(CLIENT_KEY) // publishable, extractable, NOT a secret
        .server("https://parseapi.back4app.com")
        .build()
)
// What protects data isn't key secrecy — it's CLPs + ACLs checked per request
// The Master Key bypasses every ACL and CLP: server-only, never in the app.

Chiavi API vs. token vs. JWT

Il confronto si riduce a una frase da ricordare: le chiavi identificano le app; i token autenticano le persone. Usare una chiave dove conta l’identità di una persona equivale a ricostruire male l’autenticazione; usare token per utente per contare l’uso anonimo di un’app è macchinario senza scopo.

Dove vivono le chiavi: la scala dell’archiviazione

Scritta nel codice – mai. Il codice sorgente viene copiato, forkato e committato; git ricorda per sempre, e i bot che scansionano i segreti trovano le chiavi nei commit pubblici in pochi minuti. Le variabili d’ambiente – il minimo, con la riserva su cui il cheat sheet di OWASP non gira intorno: le variabili d’ambiente trapelano dai log di errore, dai dump dei processi e dalle definizioni dei container; tengono i segreti fuori da git, non fuori dai guai. Un gestore di segreti (secrets manager) – lo standard di squadra: cifrato a riposo, con accesso controllato per servizio, verificato a ogni lettura, con rotazione centralizzata (fra le opzioni open source ci sono Vault, SOPS e Infisical). Va aggiunta l’igiene che rende le fughe sopravvivibili: chiavi generate in modo crittograficamente casuale, con prefisso (nello stile sk_live_…) perché gli scanner le riconoscano, sottoposte a hash a riposo dal lato del provider come le password, una chiave per app e per ambiente – e una scansione dei segreti (gitleaks, trufflehog) collegata alla CI, perché il commit che fa uscire una chiave fallisca prima di atterrare.

Il problema lato client, in tutta onestà

Ogni spiegazione dice “niente chiavi segrete nel codice client”; quasi nessuna dice la seconda metà: il bundle è pubblico. Il JavaScript del web è leggibile per definizione; i binari mobile vengono scompattati e svuotati delle loro stringhe di routine; l’offuscamento alza lo sforzo da minuti a ore, una volta sola. Ne seguono due conseguenze. Primo, le uniche chiavi che hanno posto in un client sono quelle pubblicabili – progettate per identificare, non per proteggere, con l’autorizzazione vera applicata lato server a ogni richiesta. Secondo, quando un client deve usare un servizio di terze parti protetto da una chiave segreta, il segreto resta dietro il backend proprio – il pattern proxy:

Quando una chiave trapela: il runbook

L’orologio conta – i bot sorvegliano i repository pubblici e sfruttano le chiavi committate in uno a cinque minuti. Nell’ordine: 1 · Revocare la chiave presso il provider – prima di indagare, prima dello standup. 2 · Sostituire – emettere la chiave nuova e distribuirla tramite configurazione, non tramite codice. 3 · Ripulire – rimuoverla dal sorgente e dalla cronologia di git; una riga cancellata sopravvive in ogni clone. 4 · Verificare – i log del provider sulla finestra della fuga: che cosa è stato letto, creato, speso. 5 · Allargare – tutto ciò che conviveva con la chiave (lo stesso .env, lo stesso repository) si presume compromesso; va ruotato anch’esso. E la riserva che distingue una risposta vera da un rituale: la revoca ferma l’uso futuro – non annulla l’esfiltrazione dei dati. Ciò che è stato preso durante la finestra è un incidente, non una rotazione.

La rotazione senza interruzioni di servizio

La rotazione mette un tetto al valore delle fughe non rilevate – una chiave rubata a cui restano 60 giorni non è lo stesso bene di una valida per sempre. Cadenza basata sul rischio: da 30 a 90 giorni per le chiavi ad ambito ampio o condivise all’esterno, fino a un anno per quelle interne a portata ristretta, immediatamente in caso di sospetta esposizione o di uscita di chiunque l’abbia detenuta. La mossa senza interruzioni è la sovrapposizione a doppia chiave: emettere la chiave nuova mentre la vecchia resta valida, migrare i deployment con calma, poi revocare la vecchia – lo stesso trucco che i sistemi a refresh token formalizzano. I regimi di conformità richiedono sempre più quel calendario; l’argomento di sicurezza non ne ha mai avuto bisogno.

Casi d’uso tipici

• Integrazione da server a server – l’habitat naturale della chiave: un servizio che si identifica presso un altro.
• Conteggio dell’uso e fatturazione – la chiave come unità che i provider contano, limitano e fatturano.
• Identificazione pubblicabile dei client – bundle di app che portano chiavi fatte per essere esposte, con l’autorizzazione altrove.
• Separazione degli ambienti – chiavi di test e di produzione che tengono gli incidenti di staging lontani dai dati di produzione.
• Contenimento degli abusi – rate limit per chiave e revoca come leve di controllo del raggio d’impatto.

Quale credenziale conviene usare? Matrice decisionale

Limiti e trade-off

• Le chiavi non provano il possesso. Una stringa bearer non offre alcun legame crittografico con il chiamante; per l’autenticazione di servizio ad alta garanzia, il TLS mutuo e le richieste firmate esistono per un motivo.
• Le credenziali statiche invecchiano male. Senza scadenza ogni fuga resta aperta fino a quando non viene notata; la rotazione è il sostituto manuale del ciclo di vita che i token ottengono gratis.
• Gli ambiti grossolani condividono troppo. Una chiave con permessi ampi è un passepartout; un ambito granulare costa amministrazione e rende in raggio d’impatto.
• Le chiavi identificano, non autenticano. Costruire una fiducia a livello di utente su un’identificazione a livello di app è il pattern di broken authentication che i revisori cercano per primo.
• La deriva dell’inventario è reale. Le chiavi inutilizzate di vecchie integrazioni restano valide fino alla cancellazione – le credenziali zombie, cugine degli endpoint zombie.

Le chiavi API su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. Il suo modello di chiavi è la sezione lato client resa concreta: l’Application ID e le chiavi client vengono spediti dentro le app per progetto – la documentazione di Back4app è esplicita, le chiavi client non sono meccanismi di sicurezza – perché l’autorizzazione non dipende mai da loro: ogni richiesta viene verificata lato server rispetto ai permessi di classe e alle ACL, così una chiave estratta concede a chi attacca esattamente ciò che ottiene un utente anonimo. L’unico vero segreto è la Master Key, che aggira ogni ACL e CLP: vive solo lato server – Cloud Code, backend fidati, variabili d’ambiente o gestore di segreti – e mai in un bundle. Le schede di codice mostrano la ripartizione in pratica; il runbook si applica alla sola master key, ed è questo il punto: un solo segreto da custodire è una postura di sicurezza, quaranta sono un foglio di calcolo.