Freigeben über

Verwendung von Azure CDN mit CORS

  • Artikel

Wichtig

Azure CDN Standard von Microsoft (klassisch) wird am 30. September 2027 eingestellt. Um Dienstunterbrechungen zu vermeiden, ist es wichtig, dass Sie Ihre Profile von Azure CDN Standard von Microsoft (klassisch) bis zum 30. September 2027 auf die Dienstebene Azure Front Door Standard oder Premium migrieren. Weitere Informationen finden Sie unter Einstellung von Azure CDN Standard von Microsoft (klassisch).

Azure CDN von Edgio wird am 4. November 2025 eingestellt. Sie müssen Ihre Workload vor diesem Datum zu Azure Front Door migrieren, um Dienstunterbrechungen zu vermeiden. Weitere Informationen finden Sie unter Häufig gestellte Fragen zur Einstellung von Azure CDN von Edgio.

Was ist CORS?

CORS (Cross Origin Resource Sharing; Ressourcenfreigabe zwischen verschiedenen Ursprüngen) ist eine HTTP-Funktion, die einer Webanwendung, die in einer Domäne ausgeführt wird, den Zugriff auf Ressourcen in einer anderen Domäne ermöglicht. Alle modernen Webbrowser eine Sicherheitseinschränkung, die als Same Origin Policybekannt ist, um die Möglichkeiten für Cross-Site Scripting-Angriffe zu verringern. Diese Einschränkung hindert eine Website daran, APIs in einer anderen Domäne aufzurufen. CORS bietet eine sichere Methode, um einem Ursprung (der Ursprungsdomäne) das Aufrufen von APIs in einem anderen Ursprung zu ermöglichen.

Funktionsweise

Es gibt zwei Arten von CORS-Anforderungen: einfache Anforderungen und komplexe Anforderungen.

Für einfache Anforderungen gilt Folgendes:

  1. Der Browser sendet die CORS-Anforderung mit einem zusätzlichen HTTP-Anforderungsheader vom Typ Ursprung. Der Wert dieses Anforderungsheaders ist der Ursprung, der die übergeordneten Seite bereitgestellt hat. Dabei handelt es sich um eine Kombination aus Protokoll, Domäne und Port. Wenn eine Seite aus HTTPS://www.contoso.com versucht, auf die Benutzerdaten im Ursprung fabrikam.com zuzugreifen, wird der folgende Anforderungsheader an fabrikam.com gesendet:

    Origin: https://www.contoso.com

  2. Der Server reagiert kann mit einem der folgenden Header reagieren:

    • Mit einem Access-Control-Allow-Origin-Header in der Antwort, der die zulässige Ursprungswebsites angibt. Beispiele:

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

    • Mit einem HTTP-Fehlercode (z. B. 403), falls der Server die ursprungsübergreifende Anforderung nach der Überprüfung des Origin-Headers nicht zulässt.

    • Mit einem Access-Control-Allow-Origin-Header mit einem Platzhalter, der alle Ursprünge zulässt:

      Access-Control-Allow-Origin: *

Für komplexe Anforderungen gilt Folgendes:

Eine komplexe-Anforderung ist eine CORS-Anforderung, bei der der Browser vor dem Senden der eigentlichen CORS-Anforderung eine Preflight-Anforderung (also einen Vorabtest) senden muss. Die Preflight-Anforderung ist eine OPTIONS-Anforderung an die gleiche URL und fordert vom Server eine Berechtigung zum Ausführen der ursprünglichen CORS-Anforderung an.

Tipp

Weitere Informationen zu CORS-Abläufen und häufigen Problemen finden Sie im CORS-Leitfaden für REST-APIs.

Platzhalter oder Szenarien mit nur einem Ursprung

CORS für Azure CDN funktioniert automatisch ohne zusätzliche Konfiguration, wenn der Header Access-Control-Allow-Origin auf Platzhalter (*) oder einen einzelnen Ursprung festgelegt ist. Das CDN speichert die erste Antwort zwischen, und nachfolgende Anforderungen verwenden den gleichen Header.

Wenn Anforderungen schon an CDN gesendet wurden, bevor CORS auf den Ursprung konfiguriert wurde, müssen Sie den Inhalt im Inhalt Ihres Endgeräts entfernen, um den Inhalt mit dem Header Access-Control-Allow-Origin erneut zu laden.

Szenarien mit mehreren Ursprüngen

Wenn Sie eine bestimmte Liste von Ursprüngen für CORS zulassen müssen, wird es etwas komplizierter. Das Problem tritt auf, wenn CDN den Access-Control-Allow-Origin -Header für den ersten CORS-Ursprung zwischenspeichert. Bei einer Folgeanforderung durch einen anderen CORS-Ursprung stellt das CDN den zwischengespeicherten Access-Control-Allow-Origin-Header bereit, dieser stimmt jedoch nicht überein. Es gibt mehrere Möglichkeiten, dieses Problem zu korrigieren.

Azure CDN Standard-Profile

Unter Azure CDN Standard von Microsoft können Sie eine Regel in der Standardregel-Engine erstellen, um den Origin-Header (Ursprung) in der Anforderung zu überprüfen. Wenn es sich hierbei um einen gültigen Ursprung handelt, legt Ihre Regel den Access-Control-Allow-Origin-Header auf den gewünschten Wert fest. In diesem Fall wird der Access-Control-Allow-Origin-Header des Ursprungsservers der Datei ignoriert und die CDN-Regel-Engine verwaltet vollständig die zulässigen CORS-Ursprünge.

Regelbeispiel mit der Standard-Regel-Engine

Tipp

Sie können Ihrer Regel zusätzliche Aktionen hinzufügen, um zusätzliche Antwortheader zu ändern, z. B. Access-Control-Allow-Methods.

Azure CDN Premium von Edgio

Unter Verwendung der Edgio Premium-Regel-Engine müssen Sie eine Regel erstellen, um den Ursprungsheader in der Anforderung zu überprüfen. Wenn es sich hierbei um einen gültigen Ursprung handelt, legt Ihre Regel den Access-Control-Allow-Origin-Header mit dem in der Anforderung bereitgestellten Ursprung fest. Wenn der im Ursprungsheader angegebene Ursprung nicht zulässig ist, sollte Ihre Regel den Access-Control-Allow-Origin-Header auslassen, der den Browser dazu bringt, die Anforderung abzulehnen.

Es gibt zwei Möglichkeiten, dieses Problem mit der Premium-Regel-Engine zu lösen. In beiden Fällen wird der Access-Control-Allow-Origin-Header des Ursprungsservers der Datei ignoriert und die CDN-Regel-Engine verwaltet vollständig die zulässigen CORS-Ursprünge.

Ein regulärer Ausdruck mit allen gültigen Ursprüngen

In diesem Fall erstellen Sie einen regulären Ausdruck, der alle Ursprünge enthält, die Sie zulassen möchten:

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

Tipp

Azure CDN Premium von Edgio verwendet Perl Compatible Regular Expressions als Engine für reguläre Ausdrücke. Sie können ein Tool wie Regular Expressions 101 verwenden, um Ihre regulären Ausdrücke zu überprüfen. Beachten Sie, dass das Zeichen „/“ in regulären Ausdrücken zulässig ist und nicht mit Escapezeichen versehen werden muss. Dieses Zeichen in Escapezeichen zu setzen ist jedoch die beste Methode und wird von einigen RegEx-Validierern erwartet.

Wenn der reguläre Ausdruck übereinstimmt, ersetzt Ihre Regel den Access-Control-Allow-Origin-Header (sofern vorhanden) des Ursprungs mit dem des Ursprungs, der die Anforderung gesendet hat. Sie können zusätzliche CORS-Header hinzufügen, wie z. B. Access-Control-Allow-Methods.

Beispiel für Regeln mit regulären Ausdruck

Anforderungsheader-Regel für jeden Ursprung

Statt reguläre Ausdrücke können Sie stattdessen eine separate Regel für jeden Ursprung erstellen, den sie zulassen möchten. Verwenden Sie dazu die Übereinstimmungsbedingung des Request Header-Platzhalters. Wie bei der Methode des regulären Ausdrucks legt die Regel-Engine allein die CORS-Header fest.

Beispiel für Regeln ohne regulären Ausdruck

Tipp

Im Beispiel weist die Verwendung des Platzhalterzeichens „*“ die Regel-Engine an, sowohl HTTP als auch HTTPS abzugleichen.