---
term: 'Sicurezza delle chiavi API'
seoTitle: 'Sicurezza delle chiavi API: archiviazione, rotazione, fughe'
headline: 'Che cos''è la sicurezza delle chiavi API?'
slug: sicurezza-delle-chiavi-api
category: auth-security
shortDefinition: '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.'
relatedTerms:
- json-web-token-jwt
- api-rate-limiting-throttling
- cors-cross-origin-resource-sharing
- data-encryption-at-rest-transit
contrastsWith:
- json-web-token-jwt
aboutTerms:
- 'Publishable vs. Secret Keys'
- 'Key Rotation'
- 'Secrets Management'
faq:
- question: 'Che cos''è una chiave API?'
answer: 'Una stringa unica che un provider di API rilascia a un''applicazione registrata e che accompagna ogni richiesta – idealmente in un header – perché il server possa identificare il chiamante, applicarne i permessi, misurare l''uso e imporre i rate limit. Dettaglio notevole: nessuno standard la definisce. Le chiavi API sono una convenzione, non un protocollo.'
- question: 'Una chiave API è una password?'
answer: 'Una chiave segreta appartiene di fatto alla classe delle password: è una credenziale bearer, quindi chiunque la detenga passa per il titolare – stessa disciplina di archiviazione, stesse conseguenze in caso di violazione. Le differenze: le chiavi identificano applicazioni invece di persone, e molte non scadono mai fino a quando non vengono ruotate.'
- question: 'Qual è la differenza tra una chiave API e un token?'
answer: 'Le chiavi identificano le app; i token autenticano le persone. Una chiave è statica, generata da un amministratore e legata a un''applicazione; un access token OAuth viene emesso all''accesso, dura poco, è rinnovabile e porta i permessi di un utente preciso. L''identificazione da server a server si adatta alle chiavi; tutto ciò che è specifico di un utente spetta ai token.'
- question: 'Dove vanno conservate le chiavi API?'
answer: 'Mai nel codice sorgente. Le variabili d''ambiente lette da un file non versionato sono il minimo – con la riserva che trapelano attraverso i log, i dump dei processi e le definizioni dei container – e un gestore di segreti è lo standard di squadra: cifrato a riposo, con accesso controllato, verificato e compatibile con la rotazione.'
- question: 'Si può mettere una chiave API nel codice frontend o mobile?'
answer: 'Solo una chiave pubblicabile progettata per questo. Tutto ciò che sta in un bundle JavaScript o in un binario di app è pubblico: l''estrazione è una routine e l''offuscamento la rallenta soltanto. Le chiavi segrete restano lato server; quando un client ha bisogno di un servizio protetto da una chiave segreta, la chiamata va instradata attraverso il backend proprio.'
- question: 'Che cosa fare quando una chiave API trapela?'
answer: 'Subito: revocare la chiave, distribuire una sostituta, ripulirla dal codice e dalla cronologia di git, esaminare i log d''uso in cerca di abusi e ruotare tutto ciò che era conservato accanto. Conviene muoversi in fretta – i bot provano le chiavi committate nei repository pubblici in pochi minuti – e ricordare che la revoca ferma l''uso futuro, non i dati già portati via.'
- question: 'Con quale frequenza vanno ruotate le chiavi API?'
answer: 'In base al rischio: da 30 a 90 giorni per le chiavi ad ambito ampio o esposte all''esterno, più a lungo per quelle interne a rischio basso, e immediatamente in caso di sospetta esposizione o di uscita di una persona dal team. La rotazione senza interruzioni si appoggia a una finestra di sovrapposizione in cui la chiave vecchia e quella nuova sono entrambe valide, il tempo che i deployment si allineino.'
- question: 'Come trapelano le chiavi API?'
answer: 'In ordine di notorietà: committate nei repository git, spedite nei bundle client e nei binari mobile, messe negli URL dove i log del server e la cronologia del browser le catturano, stampate nei log applicativi e di CI, e incollate in chat e ticket. Ogni vettore è evitabile, ed è proprio questo a rendere l''elenco deprimente.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
- name: 'OWASP Secrets Management Cheat Sheet'
url: 'https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html'
- name: 'OWASP API Security Top 10 (2023)'
url: 'https://owasp.org/API-Security/editions/2023/en/0x11-t10/'
- name: 'OWASP Key Management Cheat Sheet'
url: 'https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html'
- name: 'RFC 6750 — OAuth 2.0 Bearer Token Usage'
url: 'https://datatracker.ietf.org/doc/html/rfc6750'
- name: 'API key — Wikipedia'
url: 'https://en.wikipedia.org/wiki/API_key'
cta:
title: 'Chiavi progettate per essere spedite'
text: 'Le chiavi client di Back4app sono pubblicabili per progetto – i dati sono protetti da CLP e ACL applicate lato server, non dalla segretezza della chiave – mentre la Master Key resta dove vivono i segreti: sul server.'
linkText: 'Inizia gratis'
linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-10-09'
translationKey: api-key-security
---
**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](/glossary/it/json-web-token-jwt/); 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
| Domanda | Risposta |
| --- | --- |
| Che cosa fa una chiave | Identifica l'app · misura l'uso · ancora i [rate limit](/glossary/it/rate-limiting-api/) |
| Le due specie | Chiavi pubblicabili (fatte per essere spedite) vs. chiavi segrete (classe password) |
| La scala dell'archiviazione | Scritta nel codice: mai → variabili d'ambiente: il minimo → gestore di segreti: lo standard |
| La legge di ferro | Tutto ciò che sta in un bundle client è pubblico – va previsto che venga estratto |
| Risposta a una fuga | Revocare → sostituire → ripulire la cronologia → verificare – in minuti, non in giorni |
## La richiesta, e i due tipi di chiave
```text
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:**
```javascript
// 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
// 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.
```
**Swift:**
```swift
// 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.
```
**Kotlin:**
```kotlin
// 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
| | Chiave API | Access token OAuth | JWT |
| --- | --- | --- | --- |
| Identifica | L'applicazione | L'utente (e la concessione) | Ciò che dicono i suoi claim |
| Emissione | Una volta, da un amministratore | A ogni accesso, tramite un flusso | È un *formato*, non un'emissione |
| Durata | Fino alla rotazione (spesso mai) | Da minuti a ore | Ciò che dice `exp` |
| Ambito | Fissato alla creazione | Scope per concessione | Definito dai claim |
| Standard | Nessuno – convenzione | [OAuth 2.0](/glossary/it/oauth-2-login-social/) | RFC 7519 |
| Uso corretto | ID da server a server, conteggio | Accesso API delegato dall'utente | Trasporto di claim firmati |
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](https://cheatsheetseries.owasp.org/cheatsheets/Secrets_Management_Cheat_Sheet.html) 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:
```mermaid
flowchart LR
accTitle: Il pattern proxy che tiene le chiavi segrete lato server
accDescr: L'app client detiene soltanto una chiave pubblicabile e chiama il backend proprio. Il backend, che tiene la chiave segreta in un gestore di segreti, chiama l'API di terze parti e restituisce i risultati, così il segreto non viene mai spedito al client.
C["App client
solo chiave pubblicabile"] -->|"API propria"| B["Backend proprio
chiave segreta dal
gestore di segreti"]
B -->|"X-Api-Key: sk_live_…"| T["API di terze parti"]
T --> B --> C
X["Chi attacca scompatta il bundle"] -.->|"non trova nulla
che valga la pena rubare"| C
```
## 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](/glossary/it/rate-limiting-api/) per chiave e revoca come leve di controllo del raggio d'impatto.
## Quale credenziale conviene usare? Matrice decisionale
| Situazione | Scegliere |
| --- | --- |
| Un backend che chiama un'API di terze parti | Chiave segreta, in un gestore di segreti |
| Identificare l'app dal web o dal mobile | Chiave pubblicabile + autorizzazione lato server |
| Agire a nome di una persona autenticata | Token OAuth, non chiavi |
| Claim firmati fra servizi | [JWT](/glossary/it/json-web-token-jwt/) |
| Un client ha bisogno di un servizio a chiave segreta | Il backend proprio come proxy – il segreto non parte mai |
| Da macchina a macchina con auth tipo utente | Il flusso client credentials di OAuth |
## 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](https://owasp.org/API-Security/editions/2023/en/0x11-t10/) 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](/glossary/it/permessi-di-classe-clp/) e alle [ACL](/glossary/it/liste-di-controllo-degli-accessi-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.