Condividi tramite


Uso della rete CDN di Azure con CORS

Importante

Rete CDN di Azure Standard di Microsoft (versione classica) verrà ritirato il 30 settembre 2027. Per evitare interruzioni del servizio, è importante eseguire la migrazione dei profili di Rete CDN di Azure Standard di Microsoft (versione classica) al livello Frontdoor di Azure Standard o Premium entro il 30 settembre 2027. Per altre informazioni, vedere Ritiro di Rete CDN di Azure Standard di Microsoft (versione classica).

Rete CDN di Azure di Edgio verrà ritirato 4 novembre 2025. È necessario eseguire la migrazione del carico di lavoro in Frontdoor di Azure prima di questa data per evitare interruzioni del servizio. Per altre informazioni, vedere Rete CDN di Azure da Domande frequenti sul ritiro di Edgio.

Che cos'è CORS?

CORS (Cross Origin Resource Sharing) è una funzionalità HTTP che consente a un'applicazione Web in esecuzione in un dominio di accedere alle risorse in un altro dominio. Per ridurre il rischio di attacchi tramite script da altri siti, tutti i Web browser moderni implementano una restrizione di sicurezza nota come regola della stessa origine. Tale restrizione impedisce a una pagina Web di chiamare le API in un dominio diverso. CORS offre un modo sicuro per consentire a una origine, ovvero il dominio di origine, di chiamare le API in un'altra origine.

Funzionamento

Esistono due tipi di richieste CORS, le richieste semplici e le richieste complesse.

Per le richieste semplici:

  1. Il browser invia la richiesta CORS con un'ulteriore intestazione della richiesta HTTP Origin. Il valore di questa intestazione della richiesta è l'origine che ha gestito la pagina padre, definita come la combinazione di protocollo, dominio e porta. Quando una pagina prova ad accedere da HTTPS://www.contoso.com ai dati di un utente nell'origine fabrikam.com, a tale sito viene inviata l'intestazione di richiesta seguente:

    Origin: https://www.contoso.com

  2. Il server potrebbe rispondere con una delle intestazioni seguenti:

    • Un'intestazione Access-Control-Allow-Origin presente nella risposta, per indicare il sito di origine consentito. Ad esempio:

      Access-Control-Allow-Origin: https://www.contoso.com

    • Un codice di errore HTTP, ad esempio 403, se il server non consente la richiesta multiorigine dopo il controllo dell'intestazione Origin

    • Un'intestazione Access-Control-Allow-Origin con un carattere jolly che consente tutte le origini:

      Access-Control-Allow-Origin: *

Per le richieste complesse:

Una richiesta complessa è una richiesta CORS in cui il browser deve inviare una richiesta preliminare, ovvero un probe preliminare, prima di inviare la richiesta CORS effettiva. La richiesta preliminare chiede l'autorizzazione del server perché la richiesta CORS originale possa procedere e si tratta di una richiesta OPTIONS allo stesso URL.

Suggerimento

Per altre informazioni sui flussi CORS e i problemi comuni, vedere Guide to CORS for REST APIs (Guida di CORS per le API REST).

Scenari con caratteri jolly o singola origine

La condivisione CORS sulla rete CDN di Azure funzionerà automaticamente senza configurazioni aggiuntive quando l'intestazione Access-Control-Allow-Origin è impostata sul carattere jolly asterisco (*) o su una singola origine. La rete CDN memorizza nella cache la prima risposta e le richieste successive usano la stessa intestazione.

Se sono state inviate richieste alla rete CDN prima che la condivisione CORS venisse impostata nell'origine, è necessario eliminare il contenuto sull'endpoint e ricaricarlo con l'intestazione Access-Control-Allow-Origin.

Scenari con più origini

Se si desidera autorizzare per CORS uno specifico elenco di origini, le operazioni da eseguire sono più complesse. Il problema si verifica quando la rete CDN memorizza nella cache l'intestazione Access-Control-Allow-Origin per la prima origine CORS. Quando un'origine CORS differente effettua una richiesta successiva, la rete CDN gestisce l'intestazione Access-Control-Allow-Origin memorizzata nella cache, che però non corrisponde. Esistono diversi modi per risolvere il problema.

Profili di rete CDN Standard di Azure

Nella rete CDN di Azure Standard di Microsoft è possibile creare una regola nel motore regole Standard per controllare l'intestazione Origine nella richiesta. Se si tratta di un'origine valida, la regola imposta l'intestazione Access-Control-Allow-Origin con il valore desiderato. In questo caso, l'intestazione Access-Control-Allow-Origin proveniente dal server di origine del file viene ignorata e il motore regole della rete CDN gestisce interamente le origini CORS consentite.

Esempio di regole con il motore regole standard

Suggerimento

È possibile aggiungere altre azioni alla regola per modificare intestazioni di risposta aggiuntive, ad esempio Access-Control-Allow-Methods.

Rete CDN di Azure Premium di Edgio

Usando il motore regole Edgio Premium, è necessario creare una regola per controllare l'intestazione Origine nella richiesta. Se l'origine è valida, la regola imposta l'intestazione Access-Control-Allow-Origin sull'origine indicata nella richiesta. Se l'origine specificata nell'intestazione Origine non è consentita, la regola deve omettere l'intestazione Access-Control-Allow-Origin, che causa il rifiuto della richiesta da parte del browser.

Esistono due modi per risolvere questo problema con il motore regole Premium. In entrambi i casi, l'intestazione Access-Control-Allow-Origin proveniente dal server di origine del file viene ignorata e il motore regole della rete CDN gestisce interamente le origini CORS consentite.

Un'espressione regolare con tutte le origini valide

In questo caso viene creata un'espressione regolare che include tutte le origini che si desidera consentire:

https?:\/\/(www\.contoso\.com|contoso\.com|www\.microsoft\.com|microsoft.com\.com)$

Suggerimento

La rete CDN Premium di Azure con tecnologia Edgio usa la libreria PCRE (Perl Compatible Regular Expressions) come motore per le espressioni regolari. Per convalidare le espressioni regolari, è possibile usare uno strumento come Regular Expressions 101. Si noti che il carattere "/" è valido nelle espressioni regolari e non deve essere preceduto da un carattere di escape. Tuttavia, l'inserimento di un carattere di escape prima di "/" è considerato una procedura consigliata ed è previsto da alcuni strumenti di convalida delle espressioni regolari.

Se l'espressione regolare corrisponde, la regola specificata sostituisce l'intestazione Access-Control-Allow-Origin (se presente) proveniente dall'origine con l'origine che ha inviato la richiesta. È inoltre possibile aggiungere altre intestazioni CORS, ad esempio Access-Control-Allow-Methods.

Esempio di regole con espressione regolare

Regola intestazione richiesta per ciascuna origine.

Anziché usare espressioni regolari, è possibile creare una regola separata per ogni origine che si vuole consentire usando Request Header Wildcard (Carattere jolly intestazione richiesta) come condizione di corrispondenza. Come per il metodo delle espressioni regolari, il motore regole imposta le intestazioni CORS.

Esempio di regole senza espressione regolare

Suggerimento

Nell'esempio l'uso del carattere jolly asterisco (*) indica al motore regole di mettere in corrispondenza sia HTTP che HTTPS.