Condivisione delle risorse tra origini (CORS)

Condividere in sicurezza le risorse tra origini

Mariko Kosaka
X

Il criterio della stessa origine del browser impedisce la lettura di una risorsa da un'origine diversa. Questo meccanismo impedisce ai siti dannosi di leggere i dati di altri siti, ma impedisce anche gli utilizzi legittimi.

Le app web moderne spesso vogliono ottenere risorse da un'origine diversa, ad esempio recuperare dati JSON da un dominio diverso o caricare immagini da un altro sito in un elemento <canvas>. Queste possono essere risorse pubbliche che dovrebbero essere disponibili per la lettura da parte di chiunque, ma la norma della stessa origine ne blocca l'utilizzo. In passato, gli sviluppatori hanno utilizzato soluzioni alternative come JSONP.

La condivisione delle risorse tra origini (CORS) risolve questo problema in modo standardizzato. L'attivazione di CORS consente al server di comunicare al browser che può utilizzare un'origine aggiuntiva.

Come funziona una richiesta di risorse sul web?

richiesta e risposta
Richiesta del client e risposta del server illustrate.

Un browser e un server possono scambiare dati sulla rete utilizzando il protocollo di trasferimento ipertestuale (HTTP). HTTP definisce le regole di comunicazione tra il richiedente e il rispondente, incluse le informazioni necessarie per ottenere una risorsa.

L'intestazione HTTP negozia lo scambio di messaggi tra il client e il server e viene utilizzata per determinare l'accesso. Sia la richiesta del browser che il messaggio di risposta del server sono suddivisi in un'intestazione e un corpo.

Informazioni sul messaggio, ad esempio il tipo di messaggio o la codifica del messaggio. Un'intestazione può includere una varietà di informazioni espresse come coppie chiave-valore. L'intestazione della richiesta e l'intestazione della risposta contengono informazioni diverse.

Intestazione della richiesta di esempio

Accept: text/html
Cookie: Version=1

Questa intestazione equivale a dire "Voglio ricevere HTML in risposta. Ecco un biscotto che ho."

Intestazione della risposta di esempio

Content-Encoding: gzip
Cache-Control: no-store

Questa intestazione equivale a dire "I dati in questa risposta sono codificati con gzip. Non memorizzare nella cache."

Corpo

Il messaggio stesso. Può essere testo normale, un file binario di immagine, JSON, HTML o molti altri formati.

Come funziona CORS?

La policy della stessa origine indica al browser di bloccare le richieste multiorigine. Quando hai bisogno di una risorsa pubblica da un'origine diversa, il server che fornisce la risorsa comunica al browser che l'origine che invia la richiesta può accedere alla sua risorsa. Il browser lo ricorda e consente la condivisione delle risorse tra origini per quella risorsa.

Passaggio 1: richiesta del client (browser)

Quando il browser effettua una richiesta multiorigine, aggiunge un'intestazione Origin con l'origine corrente (schema, host e porta).

Passaggio 2: risposta del server

Quando un server vede questa intestazione e vuole consentire l'accesso, aggiunge un'intestazione Access-Control-Allow-Origin alla risposta specificando l'origine della richiesta (o * per consentire qualsiasi origine).

Passaggio 3: il browser riceve la risposta

Quando il browser vede questa risposta con un'intestazione Access-Control-Allow-Origin appropriata, condivide i dati della risposta con il sito client.

Condividere le credenziali con CORS

Per motivi di privacy, CORS viene normalmente utilizzato per le richieste anonime, in cui il richiedente non viene identificato. Se vuoi inviare cookie quando utilizzi CORS, che possono identificare il mittente, devi aggiungere intestazioni aggiuntive alla richiesta e alla risposta.

Richiesta

Aggiungi credentials: 'include' alle opzioni di recupero come nell'esempio seguente. Ciò include il cookie con la richiesta nel seguente modo:

fetch('https://example.com', {
  mode: 'cors',
  credentials: 'include'
})

Risposta

Access-Control-Allow-Origin deve essere impostato su un'origine specifica (nessun carattere jolly utilizzando *) e Access-Control-Allow-Credentials deve essere impostato su true.

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true

Richieste preflight per chiamate HTTP complesse

Quando un'app web effettua una richiesta HTTP complessa, il browser aggiunge una richiesta preliminare all'inizio della catena di richieste.

La specifica CORS definisce una richiesta complessa come segue:

  • Una richiesta che utilizza metodi diversi da GET, POST o HEAD.
  • Una richiesta che include intestazioni diverse da Accept, Accept-Language o Content-Language.
  • Una richiesta con un'intestazione Content-Type diversa da application/x-www-form-urlencoded, multipart/form-data o text/plain.

I browser creano automaticamente le richieste di preflight necessarie e le inviano prima del messaggio di richiesta effettivo. La richiesta preflight è una richiesta OPTIONS come il seguente esempio:

OPTIONS /data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: DELETE

Sul lato server, l'app che riceve la richiesta risponde alla richiesta preflight con informazioni sui metodi accettati dall'applicazione da questa origine:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, DELETE, HEAD, OPTIONS

La risposta del server può includere anche un'intestazione Access-Control-Max-Age per specificare la durata in secondi per memorizzare nella cache i risultati del preflight. Ciò consente al client di inviare più richieste complesse senza dover ripetere la richiesta di controllo preliminare.