Intestazioni di sicurezza per un'API Web

Question

Intestazioni di sicurezza per un'API Web

#1 da (22 voti)

8

Ho appena ottenuto un setup, un golang web api dietro un server caddy che ha HTTPS di default tramite Let's Encrypt, il server trasmette tutte le richieste al web API. Così sono andato in giro per testare la mia "sicurezza" del web server su siti come securityheaders.io. Mi hanno dato una F, quindi ho aggiunto le intestazioni che richiedevano e ho ottenuto un A

Access-Control-Allow-Methods "GET, POST, OPTIONS"
Strict-Transport-Security "max-age=31536000;"
Content-Security-Policy "script-src 'self'"
X-XSS-Protection "1; mode=block"
X-Content-Type-Options "nosniff"
X-Frame-Options "DENY"
-Server

Queste sono le intestazioni che attualmente ho, ma mi piacerebbe sapere se sono necessarie per la sicurezza quando ciò che sto facendo non è un sito web, ma piuttosto un server web API, qualcosa come

Access-Control-Allow-Methods "GET, POST, OPTIONS"
-Server

Quindi, in pratica, tutte le intestazioni di sicurezza sono necessarie se vuoi solo richiedere la tua API?

api proxy header

posta Whiteclaws 07.01.2017 - 01:05

fonte

1 risposta

Leggi altre domande sui tag api proxy header

Nascondere le versioni del software server ha un notevole effetto sulla sicurezza? Come criptare più di 16 byte usando AES?

score 22 · Accepted Answer

Controllare le intestazioni da una lista non è la tecnica migliore per affermare la sicurezza di un sito. Servizi come securityheaders.io possono indirizzarti nella giusta direzione, ma tutto ciò che fanno è confrontare un elenco di impostazioni proposte senza alcun contesto sulla tua applicazione. Di conseguenza, alcune delle proposte non avranno alcun impatto sulla sicurezza di un endpoint API che non serve nient'altro che le risposte JSON.

Strict-Transport-Security ha senso perché garantisce che gli utenti si colleghino direttamente al tuo sito tramite HTTPS dopo la loro prima visita e fino al raggiungimento del timeout di max-age , impedendo in tal modo gli attacchi di downgrade. Anche un endpoint API deve essere protetto con SSL, quindi mantieni l'intestazione.
Access-Control-Allow-Methods: GET, POST, OPTIONS non è un'opzione di sicurezza di per sé. Se la tua API funziona tramite CORS richieste di verifica preliminare, devi decidere quali metodi autorizzare per il cross -i siti originali da usare. La disattivazione di CORS potrebbe rendere la tua API non disponibile. Se quell'impostazione particolare è ragionevole dipende dalla tua implementazione.
X-XSS-Protection: 1; mode=block può essere un buon servizio per i siti normali perché istruisce XSS Auditor (che è implementato nei browser WebKit ma non in Firefox) per non eseguire il rendering del sito quando rileva un tentativo XSS riflesso. Ma per un'API che fornisce solo risposte JSON e non pubblica contenuti attivi, questa intestazione non porta alcun vantaggio.
X-Content-Type-Options: nosniff impedisce ai browser di formulare ipotesi sul tipo di contenuto se il sito non dichiarava correttamente il tipo. Se stai utilizzando un'API JSON, dovresti pubblicare le risposte con Content-Type: application/json . Se lo fai correttamente, non sarà necessario aggiungere la direttiva nosniff .
X-Frame-Options: Deny impedisce a qualsiasi sito web di incorporare il tuo sito in una cornice HTML. Questa opzione interrompe gli attacchi di clickjacking in cui un utente malintenzionato induce gli utenti a interagire con il tuo sito web attraverso una cornice dissimulata. Ma senza elementi interattivi esiste un rischio limitato attraverso l'inquadratura incrociata. Tuttavia, poiché vi sono attacchi avanzati che coinvolgono il trascinamento del contenuto fuori dal frame che potrebbe rivelare le risposte JSON, potresti comunque voler lasciare quell'intestazione lì.
Content-Security-Policy le intestazioni controllano il tipo di contenuto da cui è possibile interagire con il tuo sito (script, fogli di stile, immagini, ecc.). L'impostazione "script-src 'self' significa che solo gli script della stessa origine possono essere caricati. Un CSP è utile per i siti normali, ma non ha senso per il tuo endpoint API perché non vengono pubblicati contenuti attivi che potrebbero essere controllati dal CSP.
L'intestazione Server specifica le informazioni sul server e il software in esecuzione su di esso. Spesso si consiglia di non inviare l'intestazione a tutti per non rivelare nulla su software e versioni di back-end.