Cosa fa esattamente l'intestazione Access-Control-Allow-Credentials?


167

Sto cercando di capire come usare CORS e sono confuso su ciò che fa l' Access-Control-Allow-Credentialsintestazione.

La documentazione dice

Indica se la risposta alla richiesta può essere esposta o meno quando il flag delle credenziali è vero.

Ma non capisco cosa significhi "esporre" la risposta.

Qualcuno può spiegare cosa fa effettivamente questo header impostato su true (insieme al flag credenziali impostato su true)?


Risposte:


264

Per impostazione predefinita, CORS non include i cookie su richieste di origine incrociata. Ciò è diverso da altre tecniche di origine incrociata come JSON-P. JSON-P include sempre i cookie con la richiesta e questo comportamento può comportare una classe di vulnerabilità chiamata falsificazione di richieste tra siti o CSRF.

Al fine di ridurre la possibilità di vulnerabilità CSRF in CORS, CORS richiede sia al server che al client di riconoscere che è consentito includere cookie nelle richieste. In questo modo i cookie sono una decisione attiva, piuttosto che qualcosa che accade passivamente senza alcun controllo.

Il codice client deve impostare la withCredentialsproprietà su XMLHttpRequesta trueper consentire l'autorizzazione.

Tuttavia, questa intestazione da sola non è sufficiente. Il server deve rispondere con l' Access-Control-Allow-Credentialsintestazione. Rispondere con questa intestazione a truesignifica che il server consente di includere cookie (o altre credenziali dell'utente) nelle richieste di origine incrociata.

È inoltre necessario assicurarsi che il browser non blocchi i cookie di terze parti se si desidera che le richieste con credenziali di origine incrociata funzionino.

Tieni presente che, indipendentemente dal fatto che tu stia facendo richieste della stessa origine o incrociate, devi proteggere il tuo sito da CSRF (specialmente se la tua richiesta include cookie).


1
Ho chiarito la risposta per rispondere alla tua domanda. Fondamentalmente JSON-P fa male ed è meno sicuro.
mons

28
Voglio solo aggiungere un po 'a questo per commentare il significato di "esposto". Le specifiche non richiedono un pre-volo (roundtrip aggiuntivo per verificare se il server consentirà le credenziali) per le richieste GET. Invece del preflight, il browser effettuerà sempre la richiesta, inviando i cookie se withCredentialsè impostato, ma quando riceve la risposta, se è stato impostato withCredentials, consegnerà / esporrà il risultato al javascript chiamante solo se la risposta ha accesso -Control-Allow-Credentials set di intestazioni. Se nessuna intestazione, non espone la risposta, effettivamente oscurandola.
heavi5ide,

4
@ heavi5ide, Sì, anche se il browser non espone la risposta al codice client, la richiesta con cookie è stata comunque inviata (per richieste non preflight). Quindi CSRF sarebbe ancora fatto.
Pacerier,

7
Poiché questa è una risposta così popolare, aggiungerò un'altra informazione importante: oltre a configurare correttamente le intestazioni di richiesta e risposta, devi anche assicurarti che il tuo browser non blocchi i cookie di terze parti se desidera che le richieste con credenziali di origine incrociata funzionino. Vedere stackoverflow.com/a/16634887/2970321
alexw

5
Questa è una risposta così chiara che chiunque la legga per la prima volta può capire e correggere il proprio codice che non sembra funzionare bene con i cookie. Grazie!
chiede il
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.