Perchè limitare le richieste CORS (Cross-Origin Resource Sharing)?

Question

Accepted Answer

Nell'ambito delle chiamate HTTPS o request, occupano un posto speciale quelle che sono definite come Cross-Origin Resource Sharing (CORS), e che vanno in genere evitate per non avere problemi di compatibilità con i propri siti o app. Le richieste CORS sono un meccanismo basato su header HTTP che permette, di fatto, a un server di indicare qualsiasi origin (quindi un URL composto da dominio, schema o porta anche diverse da quelle su cui sta lavorando), e che potrebbe essere utilizzata per caricare risorse di vario genere (dati JSON, XML, ecc.).

Un esempio pratico di CORS

Ammettiamo di avere un sito, per esempio il nostro (trovalost.it), e di aver realizzato per lo stesso una API che possa essere richiamata mediante il sottodominio api.trovalost.it. Questa scelta garantisce di mantenere la separazione tra i due domini e i due contesti (web service e web), e in genere è cosa buona nonchè pratica corretta. Essendo una richiesta a livello di header HTTP, essa potrà funzionare in modo corretto soltanto se viene verificata la pre-condizione per eseguire il CORS, visto che si tratta di due domini diversi, cosa che viene checkata controllando il valore associato all'header HTTP dal nome:

Access-Control-Allow-Origin

e che può essere inquadrata tecnicamente studiando le caratteristiche delle request in termini di same site, same origin. Questa forma di dialogo preliminare tra API e browser, di fatto, è indispensabile perchè api.trovalost.it suggerisce uno schema di URI differente da quello del dominio originale, e anche la porta ed il protocollo potrebbero essere diversi. Se quindi il sito web all'indirizzo https://trovalost.it/ volesse prelevare dei dati interrogando un web service presente su https://api.trovalost.it/ dopo eventuale autenticazione con chiave di accesso, potrebbe idealmente procedere come segue:

var url = "https://api.trovalost.it/?key=12345&data=about:test";
fetch(url).then(success, failure)

Per fare corretto uso del protocollo CORS, l'origine valida da parte del dominio su cui gira la API dovrà essere esplicitamente aggiunto all'header HTTP.

Origin: https://api.trovalost.it

verificando, prima di inoltrare la richiesta, l'impostazione corretta del valoreAccess-Control-Allow-Origin, e lanciando la API solo in quest'ultimo caso. In genere le richieste CORS fallite possono generare un errore lato client di classe 4xx come un 404 not found, 403 forbidden e cosà¬ via. Su WordPress la diagnostica di errore è tipicamente legata ad una notifica del tipo: Cross-Origin Request Blocked il che vuol dire che stiamo provando a interrogare una risorsa che il sistema non permette di caricare (cosa che viene a volte notificata lato frontend col messaggio CORS header â€˜Access-Control-Allow-Originâ€™ missing). Se state usando un plugin di cache, assicuratevi di abilitare gli ETag e Last Modified header, disabilitando se necessario la modalità compatibilità (Compatibility mode). In altri casi, invece, può essere utile intervenire sulle direttive del file HTACCESS. Potete provare in alternative a implementare la soluzione, mediante plugin personalizzato, proposta in questo articolo.

(fonte)

Come e perchè limitare le richieste CORS (Cross-Origin Resource Sharing)

Un esempio pratico di CORS

👇 Da non perdere 👇

Ti sembra utile o interessante? Vota e fammelo sapere.

Come e perchè limitare le richieste CORS (Cross-Origin Resource Sharing)

Un esempio pratico di CORS

👇 Da non perdere 👇

Ti sembra utile o interessante? Vota e fammelo sapere.

Leggi anche: