Che cos'è CORS?

In passato, quando le tecnologie Internet erano ancora nuove, si verificavano problemi di falsificazione delle richieste tra siti (CSRF). Questi problemi inviavano false richieste dei client dal browser della vittima a un'altra applicazione.

Ad esempio, la vittima si collegava all'applicazione della propria banca. Quindi veniva indotta a caricare un sito Web esterno in una nuova scheda del browser. Il sito Web esterno utilizzava le credenziali dei cookie della vittima e inoltrava i dati alla richiesta bancaria fingendo di essere la vittima. Gli utenti non autorizzati effettuavano quindi un accesso involontario all'applicazione bancaria.

Per evitare questi problemi CSRF, tutti i browser ora implementano la policy della stessa origine.

Policy della stessa origine

Oggi, i browser impongono che i client possano inviare richieste solo a una risorsa con la stessa origine dell'URL del client. Il protocollo, la porta e il nome host dell'URL del client devono corrispondere tutti al server richiesto.

Ad esempio, si consideri il confronto dell'origine degli URL seguenti con l'URL del client http://store.aws.com/dir/page.html.

URL	Risultato	Motivo
http://store.aws.com/dir2/new.html	Stessa origine	Solo il percorso è diverso
http://store.aws.com/dir/inner/other.html	Stessa origine	Solo il percorso è diverso
https://store.aws.com/page.html	Origine diversa	Protocollo diverso
http://store.aws.com:81/dir/page.html	Origine diversa	Porta diversa (http:// è la porta 80 per impostazione predefinita)
http://news.aws.com/dir/page.html	Origine diversa	Host diverso

Pertanto, la policy della stessa origine è altamente sicura ma poco flessibile per casi d'uso reali.

La condivisione delle risorse di diversa origine (CORS) è un'estensione della policy della stessa origine. Ne hai bisogno per la condivisione autorizzata delle risorse con terze parti esterne. Ad esempio, la CORS è necessaria quando si desidera estrarre dati da API esterne pubbliche o autorizzate. È inoltre necessaria se si desidera consentire l'accesso autorizzato di terze parti alle risorse del proprio server.

In HTTP, i metodi di richiesta sono le operazioni sui dati che il client desidera che il server esegua. I metodi HTTP più comuni includono GET, POST, PUT e DELETE.

In una normale interazione CORS (cross-origin resource sharing), il browser invia contemporaneamente le intestazioni di richiesta e di controllo degli accessi. Di solito si tratta di richieste di dati GET e sono considerate a basso rischio.

Tuttavia, alcune richieste HTTP sono considerate complesse e richiedono la conferma del server prima dell'invio della richiesta effettiva. Il processo di pre-approvazione si chiama richiesta preflight.

Richieste complesse di diversa origine

Le richieste di diversa origine sono complesse se utilizzano uno dei seguenti elementi:

• Metodi diversi da GET, POST o HEAD
• Intestazioni diverse da Accept-Language, Accept o Content-Language
• Intestazioni Content-Type diverse da multipart/form-data, application/x-www-form-urlencoded o text/plain

Quindi, ad esempio, le richieste di eliminazione o modifica dei dati esistenti sono considerate complesse.

Come funzionano le richieste preflight

I browser creano richieste preflight se sono necessarie. È una richiesta OPTIONS come la seguente.

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

Il browser invia la richiesta preflight prima del messaggio di richiesta effettivo. Il server deve rispondere alla richiesta preflight con informazioni sulle richieste di diversa origine che il server è disposto ad accettare dall'URL del client. Le intestazioni delle risposte del server devono includere quanto segue:

• Access-Control-Allow-Methods
• Access-Control-Allow-Headers
• Access-Control-Allow-Origin

Di seguito viene fornito un esempio di risposta del server.

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

La risposta preflight a volte include un'intestazione Access-Control-Max-Age aggiuntiva. Questo parametro specifica la durata (in secondi) della memorizzazione dei risultati di preflight nel browser da parte del browser. La memorizzazione nella cache consente al browser di inviare diverse richieste complesse tra richieste preflight. Non è necessario inviare un'altra richiesta preflight fino alla scadenza del tempo specificato dalla durata massima.

 

Quando configuri la condivisione delle risorse di diversa origine (CORS) sul tuo server, tieni presente quanto riportato di seguito.

Definisci gli elenchi di accesso appropriati

È sempre meglio concedere l'accesso a singoli domini utilizzando elenchi separati da virgole. Evita di usare caratteri jolly a meno che tu non voglia rendere pubblica l'API. Altrimenti, l'uso di caratteri jolly ed espressioni regolari può creare vulnerabilità.

Ad esempio, supponiamo di scrivere un'espressione regolare che conceda l'accesso a tutti i siti con il suffisso permitted-website.com. Con una sola espressione, concedi l'accesso a api.permitted-website.com e news.permitted-website.com. Ma concedi anche inavvertitamente l'accesso a siti non autorizzati che potrebbero utilizzare domini come maliciouspermitted-website.com.

Evita di utilizzare un'origine nulla nella tua lista

Alcuni browser inviano il valore null nell'intestazione della richiesta per determinati scenari come richieste di file o richieste dall'host locale.

Tuttavia, non dovresti includere il valore null nell'elenco di accesso. Vengono inoltre introdotti rischi per la sicurezza in quanto possono accedere richieste non autorizzate contenenti intestazioni null.