Guten Tag, Freunde!
Ich präsentiere Ihnen die Übersetzung des Artikels "CS Visualized: CORS" von Lydia Hallie.
Jeder Entwickler musste sich mit einem Fehler auseinandersetzen
Access to fetched has been blocked by CORS policy. Es gibt verschiedene Möglichkeiten, um dieses Problem schnell zu lösen. Nehmen wir uns jedoch Zeit und schauen wir uns genauer an, was eine CORS-Richtlinie ist.
Wir müssen oft Daten anzeigen, die sich an anderer Stelle befinden. Bevor wir dies tun können, muss der Browser eine Anfrage an den Server senden, um diese Daten zu empfangen.
Angenommen, wir möchten Informationen über einen Benutzer auf unserer Site
www.mywebsite.comvon einem Server auf der Site abrufen api.website.com.
Ausgezeichnet! Wir haben gerade eine Anfrage an den Server gesendet und als Antwort JSON-Daten erhalten.
Versuchen wir nun, eine ähnliche Anfrage an eine andere Domain zu senden. Anstatt eine Anfrage mit zu
www.mywebsite.comsenden , senden wir sie mit www.anotherdomain.com.
Was ist passiert? Wir haben genau die gleiche Anfrage gesendet, aber diesmal zeigt der Browser einen Fehler an.
Wir sehen CORS in Aktion. Warum ist dieser Fehler aufgetreten und was bedeutet er?
Gemeinsame Herkunftspolitik
Es gibt etwas im Web, das als generische Ursprungsrichtlinie bezeichnet wird (im Folgenden als POP bezeichnet). Standardmäßig haben wir nur Zugriff auf Ressourcen, die denselben Ursprung haben wie der Ursprung unserer Anfrage. Zum Beispiel können wir ein Bild laden, das sich in befindet
https://mywebsite.com/image1.png.
Eine Quelle ist anders, wenn sie sich in einer anderen (Unter-) Domäne, einem anderen Protokoll oder einem anderen Port befindet.
Cool, aber warum brauchst du POP?
Nehmen wir an, es existiert nicht und Sie klicken versehentlich auf einen viralen Link, den Ihre Tante auf Facebook gesendet hat. Dieser Link leitet Sie zu einer "böswilligen Site" weiter, auf der ein eingebetteter Iframe vorhanden ist, der die Site Ihrer Bank lädt und sich dort erfolgreich mit einem Cookie anmeldet.
Die Entwickler der "bösen Website" haben sichergestellt, dass er Zugriff auf den Iframe hat und mit dem Inhalt des DOM der Website Ihrer Bank interagieren kann, um in Ihrem Namen Geld auf sein Konto zu überweisen.
Ja ... das ist ein ernstes Sicherheitsproblem. Wir möchten nicht, dass jemand ohne unser Wissen Zugang zu irgendetwas hat.
Zum Glück gibt es EVP. Diese Richtlinie beschränkt den Zugriff auf Ressourcen aus anderen Quellen.
In diesem Fall versucht die Quelle,
www.evilwebsite.comvon der Quelle aus auf die Ressource zuzugreifen www.bank.com. EPP blockiert diesen Zugriff und verhindert, dass schlechte Website-Entwickler auf Ihre Bankdaten zugreifen.
Okay, aber ... wie funktioniert es?
Client-seitige CORS
Trotz der Tatsache, dass EPP nur für Skripte gilt, "erweitern" Browser es auf alle JavaScript-Anforderungen: Standardmäßig haben wir nur Zugriff auf Ressourcen aus einer Hand.
Hmm, aber ... wir müssen oft Ressourcen aus einer anderen Quelle beziehen. Möglicherweise muss unser Frontend zur Server-API gehen, um Daten zu laden. Um Ressourcen sicher aus anderen Quellen abzurufen, implementieren Browser einen Mechanismus namens CORS.
CORS steht für Cross-Origin Resource Sharing. Obwohl Browser Ressourcen aus anderen Quellen nicht zulassen, können wir CORS verwenden, um diese Einschränkung zu ändern und gleichzeitig sicher zu bleiben.
Benutzeragenten (Browser) können CORS verwenden, um Ursprungsübergreifende Anforderungen zuzulassen, die andernfalls aufgrund einiger HTTP-Antwortheader blockiert würden.
Wenn eine Anfrage an eine andere Quelle gestellt wird, fügt der Client der HTTP-Anfrage automatisch einen Header hinzu
Origin. Der Wert dieses Headers ist die Quelle der Anforderung.
Damit der Browser das Abrufen von Ressourcen aus einer anderen Quelle ermöglicht, muss die Antwort des Servers auch einen bestimmten Header enthalten.
Serverseitige CORS
Als Backend-Entwickler können wir anderen Quellen erlauben, unsere Ressourcen abzurufen, indem wir benutzerdefinierte Header einfügen, die mit beginnen
Access-Control-*. Basierend auf dem Wert solcher Header ermöglicht der Browser die gemeinsame Nutzung von Ressourcen.
Es gibt mehrere CORS-Header, aber einer davon ist ein Muss :
Access-Control-Allow-Origin.
Die Bedeutung dieses Headers bestimmt, welche Quellen unsere Ressourcen erhalten können.
Wenn wir einen Server entwickeln, auf den zugegriffen werden
https://mywebsite.commuss, müssen wir diese Domäne zum Header hinzufügen Access-Control-Allow-Origin.
Toll. Dieser Header wird jetzt zu der an den Client gesendeten Serverantwort hinzugefügt. EPP hindert uns nicht länger daran, Ressourcen
https://api.mywebsite.comdurch Anfragen von zu erhalten https://mywebsite.com.
Der CORS-Mechanismus des Browsers überprüft, ob die Werte für
Access-Control-Allow-OriginAntwortheader und Anforderungsheader übereinstimmen Origin.
In diesem Fall ist die Quelle unserer Anfrage
https://www.mywebsite.comder in der Liste angegebene Antwortheader Access-Control-Allow-Origin.
Ausgezeichnet. Jetzt können wir Ressourcen aus anderen Quellen beziehen. Was passiert, wenn wir versuchen, dies aus einer Quelle zu tun, die nicht in aufgeführt ist
Access-Control-Allow-Origin?
Ja, CORS hat den Zugriff auf Ressourcen blockiert.
The 'Access-Control-Allow-Origin' header has a value
'https://www.mywebsite.com' that is not equal
to the supplied origin.
In diesem Fall ist die Quelle
https://www.anotherwebsite.comnicht in aufgeführt Access-Control-Allow-Origin. CORS hat die angeforderten Daten erfolgreich abgelehnt.
Mit CORS können Sie
*zulässige Quellen als Wert angeben . Dies bedeutet, dass die Ressourcen für jede Quelle verfügbar sind. Seien Sie also vorsichtig.
Access-Control-Allow-OriginIst einer der vielen Titel, die wir einstellen können. Der Back-End-Entwickler kann CORS so konfigurieren, dass bestimmte Anforderungen zugelassen (abgelehnt) werden.
Eine andere häufige Überschrift ist
Access-Control-Allow-Methods. CORS erlaubt nur Anforderungen aus anderen Quellen, die mit den angegebenen Methoden gesendet wurden.
In diesem Fall sind nur Anforderungen zulässig, die mit den Methoden GET, POST oder PUT gesendet wurden. Andere Methoden wie PATCH oder DELETE werden blockiert.
CORS behandelt sie auf besondere Weise, wenn Anforderungen mit den Methoden PUT, PATCH und DELETE gesendet werden. Diese "kniffligen" Abfragen werden manchmal als Preflight-Abfragen bezeichnet.
Vorläufige Anfragen
CORS arbeitet mit zwei Arten von Anforderungen: einfach und vorläufig. Was eine Abfrage ist, hängt von einigen ihrer Werte ab.
Eine Anforderung ist einfach, wenn sie mit den Methoden GET oder POST gesendet wird und keine zusätzlichen Header enthält. Jede andere Anfrage ist vorläufig.
Okay, aber was bedeutet Voranfrage und warum werden solche Anfragen benötigt?
Vor dem Senden der tatsächlichen Anforderung sendet der Client eine vorläufige Anforderung an den Server mit Informationen zur tatsächlichen Anforderung: zu seiner Methode, zusätzlichen Headern
Access-Control-Request-*usw.
Der Server empfängt eine vorläufige Anforderung und sendet eine leere vorläufige Antwort mit CORS-Headern. Der Browser erhält eine vorläufige Antwort und prüft, ob die tatsächliche Anforderung zulässig ist.
Wenn ja, sendet der Browser die eigentliche Anfrage und empfängt die Daten als Antwort.
Wenn nicht, blockiert CORS die Voranforderung und die tatsächliche Anforderung wird nicht gesendet. Voranfragen sind eine hervorragende Möglichkeit, um zu verhindern, dass auf dem Server auf Ressourcen zugegriffen und diese geändert werden. Dies schützt den Server vor potenziell unerwünschten Anforderungen aus anderen Quellen.
Um die Anzahl der wiederholten Anforderungen zu verringern, können wir die vorläufige Antwort zwischenspeichern, indem wir
Access-Control-Max-Ageder CORS-Anforderung einen Header hinzufügen . Dadurch wird vermieden, dass die vorläufige Anforderung erneut gesendet wird.
Referenzen
Cookies, Autorisierungsheader und TLS-Zertifikate werden standardmäßig nur für Anforderungen aus einer einzigen Quelle installiert. Möglicherweise müssen wir diese Berechtigungen jedoch in einer Anforderung aus einer anderen Quelle verwenden. Vielleicht möchten wir Cookies in die Anfrage aufnehmen, mit der der Server den Benutzer identifizieren kann.
Obwohl CORS standardmäßig keine Berechtigungen enthält, können wir dies mit einem Header ändern
Access-Control-Allow-Credentials.
Wenn wir Cookies und andere Autorisierungsheader aus einer anderen Quelle in unsere Anfrage aufnehmen möchten, müssen wir das Feld auf einen
withCredentialsWert truein der Anfrage setzen und den Header Access-Control-Allow-Credentialszur Antwort hinzufügen .
Fertig, jetzt können wir Anmeldeinformationen aus einer anderen Quelle in unsere Anfragen aufnehmen.
Ich hoffe der Artikel war hilfreich für Sie. Danke für die Aufmerksamkeit.