Perché un’API non dovrebbe mai reindirizzare HTTP su HTTPS

Le discussioni riguardanti le pratiche di sicurezza delle API sono spesso ricche di pareri divergenti e osservazioni critiche. Un tema specifico che è emerso recentemente è l’opportunità o meno di reindirizzare le richieste API da HTTP a HTTPS. Molti sostenitori della sicurezza ritengono che un’API non dovrebbe mai supportare HTTP del tutto, un’opinione supportata anche dalle problematiche che emergono durante l’implementazione di tale pratica.

Una delle principali preoccupazioni riguarda la modalità con cui certi ambienti di runtime, come Node.js, gestiscono questi reindirizzamenti. Alcuni strumenti, come `fetch` integrato in Node.js, seguono tranquillamente i reindirizzamenti senza alcun allarme, una caratteristica che dovrebbe far riflettere ogni sviluppatore. La questione centrale è se `fetch` rispetti o meno l’HSTS (HTTP Strict Transport Security). L’HSTS è un meccanismo fondamentale per forzare le connessioni HTTPS e quindi evitare il rischio di intercettazioni (MITM, man-in-the-middle), ma il problema più grande è dove e come questi stati di sicurezza vengano memorizzati.

Un altro aspetto rilevante riguarda la gestione interna delle configurazioni. Un concetto che emerge è la potenzialità di creazione di file di stato non controllati, che potrebbero creare incongruenze o errori nel caso di file system in sola lettura o backup non corretti. Per un ambiente di sviluppo, la richiesta di specificare un percorso per memorizzare gli stati di sicurezza, o abilitare flag come `insecure_ignore_hsts=true`, può sembrare una soluzione temporanea che però non risolve alla radice il problema della gestione sicura delle connessioni.

Un punto interessante sollevato dai commentatori è la discrepanza tra l’uso di HSTS per browser e API. L’HSTS è stato concepito principalmente per risolvere un problema umano, come l’inserimento manuale di URL nella barra degli indirizzi del browser, e non è necessariamente adatto per client stateless come quelli utilizzati nelle API. In effetti, la corretta gestione di una risposta che include un redirect da HTTP a HTTPS e un’intestazione HSTS comporterebbe una complessità aggiuntiva che potrebbe essere evitata.

La proposta più pragmatica sembra essere quella di disabilitare completamente l’interfaccia HTTP su server API. Se un’API non risponde affatto su porta 80 (HTTP), ogni tentativo di connessione verrà immediatamente rifiutato, prevenendo l’eventuale esposizione di chiavi API o altre informazioni sensibili. Ciò forza gli sviluppatori a utilizzare correttamente HTTPS sin dall’inizio, riducendo i rischi associati a una configurazione sbagliata o a una disattenzione.

È importante notare che non tutti sono d’accordo con l’idea di eliminare completamente HTTP. Alcuni sostengono che disabilitare HTTP potrebbe introdurre problemi di configurazione aggiuntivi o complicazioni nelle procedure di debugging. Inoltre, una risposta HTTP che restituisce un codice di stato e un messaggio informativo, come suggerito da alcuni, può aiutare a identificare subito l’errore e a correggere la configurazione. Tuttavia, gli esperti sicurezza avvertono che anche in questo caso, l’invio delle credenziali non criptate è un rischio che non dovrebbe essere preso alla leggera.

Oltre alla configurazione del server, è evidente che le librerie dei client devono svolgere un ruolo attivo per garantire connessioni sicure. Ad esempio, sarebbe opportuno che le librerie HTTP più utilizzate, come `libcurl`, verificassero e rispettassero le intestazioni HSTS, o che almeno richiedessero configurazioni esplicite per il supporto HSTS. Questo aumenterebbe il livello di sicurezza e conformità.

Infine, considerate le discussioni emerse e l’attuale panorama delle minacce online, è chiaro che la sicurezza delle API deve essere una priorità assoluta. Semplici misure come non reindirizzare automaticamente HTTP su HTTPS e implementare controlli rigorosi sulle connessioni possono prevenire molti problemi. Gli sviluppatori devono essere educati a comprendere i rischi e a impostare misure preventive già nella fase di sviluppo, affinché i loro servizi rimangano robusti e sicuri nel tempo.