Vai al contenuto principale
Le tue chiavi e token API devono essere protetti con la massima attenzione.  Queste credenziali sono direttamente collegate alla tua App sviluppatore e agli account X che ti hanno autorizzato a inviare richieste per loro conto. Se le tue chiavi vengono compromesse, soggetti malintenzionati potrebbero usarle per effettuare richieste agli endpoint di X per conto della tua App sviluppatore o dei suoi utenti autorizzati; ciò potrebbe farti raggiungere limiti di velocità imprevisti, consumare la tua quota di accesso a pagamento o persino causare la sospensione della tua App sviluppatore. Le sezioni seguenti includono le best practice da considerare quando gestisci le tue chiavi e token API.

​
Rigenerare le chiavi e i token API

Se ritieni che le tue chiavi API siano state esposte, rigenerale seguendo questi passaggi:
  1. Vai alla pagina “Projects and Apps” del developer portal.
  2. Fai clic sull’icona “Keys and tokens” (🗝) accanto all’App interessata.
  3. Fai clic sul pulsante “Regenerate” accanto al set di chiavi e token che desideri rigenerare.
Se preferisci rigenerare gli Access Tokens o i Bearer Token in modo programmatico, puoi farlo utilizzando i nostri endpoint di autenticazione.

​
Mantenere un file centralizzato per le credenziali

Utilizzare un file come .env o un file .yaml per conservare le credenziali può essere utile, ma assicurati di avere un file .gitignore ben configurato che impedisca di aggiungerle per errore a un repository Git. 

​
Variabili d’ambiente

Scrivere codice che usa variabili d’ambiente può essere utile.  Ecco un esempio in Python: 
import os

consumer_key = os.environ.get("CONSUMER_KEY")

consumer_secret = os.environ.get("CONSUMER_SECRET")
Nel terminale, esegui un comando come il seguente: 
export CONSUMER_KEY='xxxxxxxxxxxxxxxxxxx'
export CONSUMER_SECRET='xxxxxxxxxxxxxxxxxxxxxxx'

​
Codice sorgente e controllo delle versioni

Gli errori di sicurezza più comuni commessi dagli sviluppatori consistono nell’avere API Key e chiavi e token inseriti nel codice sorgente in sistemi di controllo delle versioni accessibili come GitHub e Bitbucket. Molti di questi repository di codice sono pubblicamente accessibili. Questo errore è così frequente nei repository pubblici che esistono bot redditizi che effettuano scraping alla ricerca di API Key.
  • Usa le variabili d’ambiente del server. Memorizzando le API Key nelle variabili d’ambiente, le tieni fuori dal codice e dal controllo delle versioni. Questo ti consente anche di usare facilmente chiavi diverse per ambienti diversi.
  • Usa un file di configurazione escluso dal controllo del codice sorgente. Aggiungi il nome del file al file .gitignore per escluderne il tracciamento da parte del sistema di controllo delle versioni.
  • Se rimuovi le API Key dal codice dopo aver utilizzato il controllo delle versioni, è probabile che le API Key siano ancora accessibili consultando le versioni precedenti della codebase. Rigenera le API Key, come descritto nella sezione successiva.

​
Database

Se devi archiviare i tuoi access token in un database, tieni presenti le seguenti indicazioni:
  • Limita l’accesso al database in modo che gli access token siano leggibili solo dal proprietario del token.
  • Limita i privilegi di modifica/scrittura alla tabella del database che contiene gli access token: questo dovrebbe essere automatizzato con il sistema di gestione delle chiavi.
  • Cifra gli access token prima di archiviarli in qualsiasi data store.

​
Strumenti di gestione delle password

Strumenti di gestione delle password come 1Password o LastPass possono essere utili per conservare le tue chiavi e token in un luogo sicuro. Potresti voler evitare di condividerli all’interno di uno strumento di gestione delle password condiviso dal team.
Esistono due tipi di archiviazione web: LocalStorage e SessionStorage. Sono stati introdotti come miglioramento rispetto ai cookie, poiché la capacità di archiviazione del web storage è molto superiore a quella dei cookie. Tuttavia, ciascuna di queste opzioni presenta vantaggi e svantaggi.   Web Storage: LocalStorage Qualsiasi elemento archiviato nel web storage locale è persistente. Ciò significa che i dati rimangono finché non vengono esplicitamente eliminati. A seconda delle esigenze del tuo progetto, questo potrebbe essere un aspetto positivo. Tuttavia, occorre prestare attenzione all’uso di LocalStorage, poiché qualsiasi modifica o aggiunta ai dati sarà disponibile in tutte le visite future alla pagina web in questione. In genere non consigliamo di utilizzare LocalStorage, sebbene possano esserci eccezioni. Se decidi di usarlo, è utile sapere che supporta la same-origin policy, quindi tutti i dati qui archiviati saranno disponibili solo dalla stessa origine. Un ulteriore vantaggio in termini di prestazioni è la diminuzione del traffico client-server, poiché i dati non devono essere inviati al server per ogni richiesta HTTP.   Web Storage: SessionStorage SessionStorage è simile a LocalStorage, ma la differenza fondamentale è che non è persistente. Una volta chiusa la finestra (o la scheda, a seconda del browser) utilizzata per scrivere in SessionStorage, i dati vengono persi. Questo è utile per limitare l’accesso in lettura al tuo token all’interno di una sessione utente. In termini di sicurezza, l’uso di SessionStorage è generalmente preferibile a LocalStorage. Come per LocalStorage, anche con SessionStorage valgono i vantaggi della same-origin policy e della riduzione del traffico client-server.   Cookie I cookie sono il modo più tradizionale per archiviare dati di sessione. Puoi impostare un tempo di scadenza per ciascun cookie, il che consente una revoca più agevole e la limitazione dell’accesso. Tuttavia, il traffico client-server aumenterà sicuramente quando si utilizzano i cookie, poiché i dati vengono inviati al server per ogni richiesta HTTP. Se decidi di usare i cookie, devi proteggerti dal dirottamento di sessione. Per impostazione predefinita, i cookie vengono inviati in chiaro su HTTP, rendendo il loro contenuto vulnerabile al packet sniffing e/o ad attacchi man-in-the-middle, in cui gli aggressori possono modificare il tuo traffico. Dovresti sempre imporre l’uso di HTTPS per proteggere i dati in transito. Questo garantisce riservatezza, integrità (dei dati) e autenticazione. Tuttavia, se la tua applicazione o il tuo sito sono disponibili sia tramite HTTP sia tramite HTTPS, è consigliabile usare anche il flag “Secure” sul cookie. In questo modo si impedisce agli aggressori di poter inviare a un utente link alla versione HTTP del tuo sito e intercettare la conseguente richiesta HTTP generata. Un’ulteriore difesa contro il dirottamento di sessione quando si utilizzano i cookie consiste nel verificare nuovamente l’identità dell’utente prima di eseguire azioni ad alto impatto. Un altro flag da considerare per migliorare la sicurezza dei cookie è “HttpOnly”. Questo flag indica al browser che il cookie in questione deve essere accessibile solo dal server. Qualsiasi tentativo da parte di script lato client verrebbe bloccato da questo flag, contribuendo a proteggere dalla maggior parte degli attacchi di cross-site scripting (XSS).
⌘I