Ho notato che alcuni siti Web fanno questo e non sono sicuro che sia normale o meno. Ad esempio, in alcuni siti Web, vado nell'impostazione e posso creare una chiave API che sarà visibile in testo normale. Inoltre, sembra che molte richieste HTTP abbiano una chiave API visibile nell'URL. Qualcosa come questo "https://www.myWebsite/user?apiKey=\(apiKey)" . Qualche idea su questo è apprezzata.
"Normale" potrebbe essere la scelta sbagliata di parole per la tua domanda. La vera domanda è ... "È sicuro?"
Rompendo la domanda in parti diverse, ecco la mia risposta a una risposta:
1. È sicuro che un sito mi fornisca una chiave API?
Fornire la propria chiave API non è un problema, poiché è la tua chiave. Questo è vero finché la pagina viene pubblicata utilizzando https. La pubblicazione della pagina non crittografata consentirebbe a chiunque tra te e il server web di vedere anche la tua chiave API.
2. Una chiave API può essere passata tramite URL e rimanere segreta?
No. Passare una chiave API tramite l'URL significa che la chiave è memorizzata nei log del server, nella cronologia di un browser, visibile alle estensioni del browser, copiata / incollata accidentalmente da un utente, ecc. Non è più un segreto. Questo è vero anche se la pagina viene pubblicata tramite https.
3. Una chiave API deve essere tenuta segreta?
Questa domanda potrebbe essere una buona da esplorare. Forse il servizio a cui ti stai riferendo fornisce una chiave API e una chiave segreta. La chiave API può essere esposta tramite URL ma la chiave segreta deve essere utilizzata per calcolare una determinata intestazione che deve anche accompagnare la richiesta.
Un altro esempio potrebbe essere un'API che dovrebbe essere chiamata tramite JavaScript. In questo caso, qualsiasi cosa nel codice sarà esposta al client. Di nuovo, il servizio fornito potrebbe aspettarsi che una chiave derivata dalla tua chiave segreta venga passata tramite il servizio.
In alternativa, forse nessuna delle chiavi è segreta, ma il servizio utilizza la whitelist degli indirizzi IP per garantire che le chiavi possano essere utilizzate solo dal server. Potrebbero anche eseguire il controllo del nome host e consentire all'utente di specificare nomi host validi nel proprio account per i quali è possibile utilizzare la chiave.
Riepilogo
In definitiva, la tecnica che un servizio sceglie di utilizzare per proteggere le sue chiavi e le sue chiavi segrete deve corrispondere alla necessità di mantenerle segrete, o alla necessità di proteggere gli utenti non autorizzati dal chiamare il servizio. In alcuni casi, non importa se qualcuno usa le tue chiavi per chiamare il servizio.
È normale rendere visibile la chiave API. E alla fine della giornata, puoi sempre estrarre la chiave dal tuo browser non importa come sia protetta. Per quanto riguarda il "testo in chiaro", non è davvero possibile cifrare in modo significativo la chiave se questo è ciò che intendi. Alla fine della giornata, è improbabile che si abusa della tua chiave API, in quanto in realtà appartiene a te. L'unico svantaggio di averlo nell'URL è una leggera possibilità che tu invii a qualcuno la chiave come parte di un link.
Ciò che è molto sospetto sul tuo esempio è che è http: e non https :. Devi MAI inviare chiavi, password o elementi sensibili su http. Non sono sicuro che questo faccia parte della domanda o dell'errore da parte tua.
Cercherò di rispondere alla tua domanda sulla "normalità" di questa pratica, ma richiede un po 'di configurazione. Supponiamo che stai servendo una pagina HTML, che rende una richiesta AJAX a qualche API di terze parti. Ti sei registrato per un piano con loro e ti forniscono una chiave API.
Chiunque guardi all'origine della tua pagina HTML può trovare la chiave API e usarla per i propri scopi. La solita raccomandazione è di fare in modo che la tua pagina HTML effettui la richiesta non all'API esterna, ma al tuo server, dove hai implementato un'API proxy. Stai aggiungendo la chiave API alla richiesta, la invii all'API esterna e restituisci la risposta al browser. In questo modo la tua chiave API rimane segreta finché usi https e nessuno si rompe nel tuo server.
Tuttavia, che cosa hai effettivamente realizzato a questo punto? Hai creato l'equivalente di un relay di posta aperta. Proprio come gli spammer utilizzano un relay di posta aperto per inviare le loro email di massa senza pagare per un servizio legittimo, chiunque può ora utilizzare il server come proxy per l'API di terze parti. In altre parole: invece di chiamare direttamente Google Maps, chiamano il tuo server e stai chiamando Google Maps per loro con la tua chiave API segreta.
A questo punto potresti anche rendere pubblica la tua chiave API, perché in questo modo risparmierai almeno il traffico generato da centinaia di siti non collegati che ti utilizzano come proxy conveniente. Questo potrebbe essere il pensiero alla base della pratica di non tenere segrete le chiavi API di terze parti, risparmiando il traffico a spese dei costi di gestione del tuo piano API di terze parti.
Il problema di sicurezza è diventato una decisione commerciale: forse l'API esterna ha un generoso livello gratuito e in realtà non stai pagando per richieste "indesiderate". O forse stai pagando per quelle richieste, ma il valore commerciale del tuo servizio effettivo ne minimizza i costi. Forse mettere un livello di autenticazione di fronte al tuo servizio renderebbe così scomodo per i tuoi utenti, che stai perdendo affari. O forse (questo è il mio preferito) hai progettato la tua app Web in modo che il risultato della richiesta all'API esterna sia relativamente inutile al di fuori del contesto della tua app. Supponiamo che stiate recuperando le indicazioni stradali tramite Google Maps dal punto X alla vostra azienda (e non a un punto arbitrario Y).
Se non vuoi risolvere questo problema a livello di business, ma piuttosto approfondire la sicurezza, allora (per quanto vedo) devi essere in grado di distinguere tra richieste volute e indesiderate. Se le richieste arrivano direttamente dal browser dell'utente all'API esterna, non c'è modo di farlo. A meno che non si richieda a tutti gli utenti di fornire le proprie credenziali per l'accesso al provider dell'API esterno, il che non è realistico nella maggior parte dei casi d'uso (e potrebbe essere un problema di sicurezza dal punto di vista degli utenti).
Alla fine della giornata è necessario che le richieste passino attraverso il server e filtrino le richieste indesiderate. Il modo in cui lo implementa dipende dalla tua applicazione.
Leggi altre domande sui tag api account-security