CORS erklärt: Bedeutung der domänenübergreifenden gemeinsamen Nutzung von Ressourcen in der Webentwicklung

Sie fragen sich, was CORS (Cross-Origin Resource Sharing) ist?

In Spionagefilmen haben Sicherheitskräfte eine codiert Art der Informationsübertragung untereinander. Da sie meistens Informationen übertragen, die gegen sie verwendet werden können, wenn sie in die Hände ihrer Feinde fallen, müssen sie sicherstellen, dass diejenigen, die die Informationen erhalten, vertrauenswürdige Parteien sind. Gleiches gilt für diejenigen, die diese Informationen senden. Wenn Sender und Empfänger vertrauenswürdig sind, kann die Glaubwürdigkeit und Sicherheit der Informationen gewährleistet werden.

Eine Nachbildung dieses Szenarios findet in der Kommunikation zwischen Browsern und Webservern statt und wird als Same-Origin-Policy bezeichnet.

What is the Same-Origin Policy?

Ist Ihnen schon einmal aufgefallen, dass Webseiten nicht auf Ressourcen von einer anderen Website zugreifen können? Das liegt an der Same-Origin-Richtlinie, einer Sicherheitsfunktion in Webbrowsern, die verhindert, dass Webseiten auf Ressourcen (wie Cookies, Skripte und andere Daten) von einer anderen Domäne als der, die die Seite bereitgestellt hat, zugreifen.

Ein Ursprung wird durch die Kombination aus Protokoll, Domäne und Portnummer einer URL definiert. Die meisten Browser, einschließlich Chrome, Firefox, Safari und Edge, implementieren eine Same-Origin-Richtlinie, um Ihre Daten zu schützen.

Nun, warum brauchen wir diese Politik? Um dies zu verstehen, werfen wir einen Blick darauf, wie das Internet funktioniert. Sie besuchen eine Website, an die Ihr Browser eine Anfrage sendet Server-Hosting diese Website, und der Server antwortet, indem er die Ressourcen zurücksendet, die zum Anzeigen der Seite erforderlich sind. Diese Ressourcen können HTML, CSS, JavaScript und Bilder umfassen. 

Stellen Sie sich vor, eine Webseite könnte auch Anfragen an andere Domains stellen. Um mit unserer Spionagefilm-Prämisse fortzufahren, möchte ein Geheimagent einer anderen Agentur Kontakt mit einem Agenten einer anderen Organisation oder eines anderen Landes aufnehmen, um Zugang bitten und Informationen austauschen. Wird ihnen diese Möglichkeit eingeräumt, eröffnet dies der späteren Organisation enorme Sicherheitslücken. Sie können vertrauliche Informationen stehlen und ihnen möglicherweise Schaden zufügen. 

Die Same-Origin-Policy ist in Kraft, um genau dieses Problem anzugehen. Obwohl es einige Missverständnisse über SOP gibt, bedeutet dies nicht, dass Sie keine Ressourcen von verschiedenen Ursprüngen laden oder Informationen an einen anderen Ursprung senden können. 

SOP legt jedoch Regeln fest, die den Zugriff und die Interaktion zwischen verschiedenen Ressourcen wie Skripten, CSS, iFrames, Bildern und Videos einschränken. Es ist wie ein Wächter, der Webseiten in ihrer eigenen Domain hält und sie daran hindert, auf Ressourcen aus anderen Domains zuzugreifen. 

Dies schützt Sie vor böswilligen Angriffen, die Ihre Daten stehlen oder Sie dazu verleiten könnten, unerwünschte Aktionen auszuführen.

What is CORS?

In einem realen Fall, in dem Sicherheitsmitarbeiter die Regel festlegen, dass die Kommunikation nur zwischen ihren Mitarbeitern als Sicherheitsmaßnahme erfolgen soll, ähnelt dies der Richtlinie mit demselben Ursprung. Es kann jedoch Fälle geben, in denen sie mit der Außenwelt interagieren müssen. Oder mit Mitarbeitern anderer Sicherheits-Outfits können sie dafür eine andere Sicherheitsmaßnahme implementieren überprüfen diese Agenten. Diese Überprüfung kann je nach den beteiligten Mitarbeitern auf unterschiedliche Weise erfolgen. Bei der Kommunikation im Internet CORS ist der Mechanismus, der es Browsern ermöglicht, auf Ressourcen zuzugreifen, auf die sie ursprünglich nicht zugreifen können, da die Ressource einen anderen Ursprung hat.

Cross-Origin Resource Sharing (CORS) ist ein Mechanismus, der mithilfe zusätzlicher HTTP-Header die Browser anweist, einer Webanwendung, die an einem Ursprung ausgeführt wird, Zugriff auf ausgewählte Ressourcen eines anderen Ursprungs zu gewähren.

Ich habe mehr als einmal über Herkunft gesprochen, und Sie fragen sich wahrscheinlich, was das bedeutet. Ein Ursprung wird durch das Protokoll, die Domäne und den Port der URL definiert. Wenn Sie Ihre API an einem Ursprung wie https://api.geekflare.com:3001 und Ihr Frontend an https://geekflare.com haben, werden die Ursprünge als unterschiedlich bezeichnet. In dieser Situation benötigen Sie CORS, um an beiden Enden auf Ressourcen zugreifen zu können.

Wenn Anforderungen an einen Server gestellt werden, senden die Browser (Client) und Server Anforderungen und Antworten. HTTP-Header sind enthalten. Unter diesen Headern sind zusätzliche Header enthalten, um zu verhindern, dass der Browser die Kommunikation blockiert.

Warum blockiert der Browser die Kommunikation?

Die Sicherheitsfunktionen des Browsers. Dies ist der Fall, wenn die Anforderung von einem anderen Ursprung als dem des Kunden stammt. Die zusätzlichen Header, die als Ergebnis von CORS enthalten sind, können dem Client mitteilen, dass er die empfangene Antwort verwenden kann.

Common Issues with CORS

Als Webentwickler benötigen Sie Zugriff auf Ressourcen aus verschiedenen Domänen – beispielsweise beim Erstellen einer Webanwendung, die verwendet APIs aus mehreren Quellen. Sie implementieren CORS, wodurch Webserver angeben können, welche anderen Domänen auf ihre Ressourcen zugreifen dürfen, sodass Sie weiterhin die gewünschten Web-Apps erstellen können. Dieses Verhalten wird auf der Serverseite implementiert, sodass es auf der Clientseite nicht neu konfiguriert werden kann. 

Wenn Sie auf einen CORS-Fehler stoßen, bedeutet dies, dass der Server Ihre Anfrage zum Zugriff auf seine Ressourcen von einer anderen Domäne abgelehnt hat, weil er die erforderlichen Sicherheitsstandards nicht erfüllt.

Dies kann passieren, wenn der Server nicht die richtigen Einstellungen vorgenommen hat. Aber keine Sorge – es gibt eine einfache Möglichkeit, das Problem zu beheben. Stellen Sie einfach sicher, dass der Access-Control-Allow-Origin-Header richtig konfiguriert ist. Dadurch wird dem Server mitgeteilt, welche Domänen auf seine Ressourcen zugreifen dürfen. Wenn er also nicht richtig eingerichtet ist, können Probleme auftreten.

Hier sind einige andere Probleme, auf die Sie stoßen können: 

• Wenn Sie versuchen, a nicht einfache HTTP-Methode (wie DELETE oder PUT) in einer Cross-Origin-Resource-Sharing-Anfrage, ist es wichtig sicherzustellen, dass der Server dies zulässt. Browser lassen standardmäßig nur einfache Methoden zu, daher müssen Sie den Header Access-Control-Allow-Methods explizit festlegen, wenn Sie eine andere Methode verwenden möchten.
• Wenn Sie solche Anfragen stellen, müssen Sie außerdem darauf achten, Anmeldeinformationen (wie Cookies oder Autorisierungsheader) von dem Browser zu senden, den der Server zulässt.  
• Darüber hinaus antwortet der Server nicht korrekt, wenn die „Preflight“-Anfrage für eine nicht einfache Anfrage (z. B. eine mit benutzerdefinierten Headern) ergibt, dass sie nicht unterstützt wird.
• Wenn eine Webseite versucht, auf Ressourcen zuzugreifen (gehostet auf einem Content Delivery Network) wie Bilder, Skripts oder Stylesheets von einer anderen Domäne, lässt der Server, der die Ressource hostet, möglicherweise keine Anfragen von der Domäne zu, auf der die Seite gehostet wird. 

Glücklicherweise gibt es einige Möglichkeiten, dieses Problem zu lösen. Eine Lösung besteht darin, den Server so zu konfigurieren, dass Cross-Origin-Anforderungen zugelassen werden, indem die entsprechenden Header gesendet werden.

Eine weitere Option besteht darin, einen Proxyserver zu verwenden, um die Anforderung im Namen Ihrer Webanwendung zu stellen, oder JSON-P zu verwenden, um die Antwort in eine Callback-Funktion zu verpacken.

Darüber hinaus gibt es Bibliotheken, die Cross-Origin-Anfragen auf der Client-Seite vereinfachen, indem sie die Header handhaben und eine Anfrage-API ohne Probleme bereitstellen.

Indem Sie diese verschiedenen Lösungen ausprobieren, können Sie diese Probleme umgehen und sicherstellen, dass Ihre Webanwendung auf die Ressourcen zugreifen kann, die sie benötigt, um ordnungsgemäß zu funktionieren.

Ein Wort der Vorsicht – Diese Techniken können ihre eigenen Sicherheitsrisiken haben, daher ist es wichtig, sie sorgfältig zu verwenden!

CORS Headers

Einer der sichere Header Dies kann entweder ein Antwort- oder ein Anforderungsheader sein.

Antwort-Header

Dies sind die Header, die der Server in seiner Antwort zurücksendet.

• Access-Control-Allow-Origin: <origin>: Hiermit wird der Ursprung angegeben, der auf die Ressource auf dem Server zugreifen darf. Es kann angegeben werden, dass nur Anforderungen von einem bestimmten Ursprung zulässig sind - Access-Control-Allow-Origin: https://geekflare.com, oder dass der Ursprung keine Rolle spielt - Access-Control-Allow-Origin: *.
• Access-Control-Expose-Headers: <headers>: Wie der Name schon sagt, werden hier die Header aufgelistet, auf die der Browser Zugriff hat.
• Access-Control-Max-Age: <seconds>: Dies gibt die Dauer an, für die die Antwort einer Preflight-Anforderung zwischengespeichert werden kann.
• Access-Control-Allow-Credentials: <boolean>: Dies zeigt an, dass der Browser die Antwort verwenden kann, wenn die erste Anforderung mit einem Berechtigungsnachweis gestellt wurde.
• Access-Control-Allow-Methods: <methods>: Dies gibt die Methode (n) an, die beim Versuch, auf eine Ressource zuzugreifen, zulässig sind.
• Access-Control-Allow-Headers: <headers>: Dies zeigt an, dass die HTTP-Header in einer Anforderung verwendet werden können.

Hier ist ein Beispiel dafür, wie die Antwort aussehen wird

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET,HEAD,PUT,PATCH,POST,DELETE
Vary: Access-Control-Request-Headers
Access-Control-Allow-Headers: Content-Type, Accept
Content-Length: 0
Date: Sat, 16 Nov 2019 11:41:08 GMT+1
Connection: keep-alive

Header anfordern

Hier sind die Header, die die Anforderung eines Clients enthalten sollte, um den CORS-Mechanismus nutzen zu können.

• Origin: <origin>: Dies gibt den Ursprung der Client-Anfrage an. Wenn Sie, wie bereits erwähnt, mit einem Frontend und Backend arbeiten, ist dies der Host Ihrer Frontend-Anwendung.
• Access-Control-Request-Method: <method>: Dies wird in einer Preflight-Anfrage verwendet, um die HTTP-Methode anzugeben, mit der die Anfrage gestellt wird.
• Access-Control-Request-Headers: <header>: Dies wird in einer Preflight-Anforderung verwendet, um die HTTP-Header anzugeben, die für die Anforderung verwendet werden.

Hier ist ein Beispiel dafür, wie eine Anfrage aussehen wird

curl -i -X OPTIONS localhost:3001/api \
-H 'Access-Control-Request-Method: GET' \
-H 'Access-Control-Request-Headers: Content-Type, Accept' \
-H 'Origin: http://localhost:3000'

Preflight Requests

Was könnte es bedeuten, nachdem hier und da Preflight-Anfragen erwähnt wurden?

Preflight-Anforderungen treten auf, wenn der Client vor der Hauptanforderung eine Preflight-Anforderung senden muss. Das Preflight-Anfrage ist eher ein Sonde um festzustellen, ob der Server die Hauptanforderung unterstützt, die gestellt werden soll. Wenn eine positive Bestätigung erhalten wird, wird die Hauptanforderung gesendet.

Wenn eine Anfrage keine Preflight-Anfrage ist, wird sie als a bezeichnet einfache Anfrage.

Implementing CORS

Meistens möchten Sie Dinge im Backend Ihrer Anwendung einrichten. Die Implementierung hängt vom verwendeten Framework ab. In diesem Tutorial werden wir uns ansehen, wie es in NodeJS und Rails gemacht wird.

Schienen

Ich empfehle Ihnen, die Rack-Cors Juwel. Dann müssen Sie dies zu Ihrem hinzufügen config/application.rb Datei.

config.middleware.insert_before 0, Rack::Cors do
  allow do
    origins '*'
    resource '*',
       headers: :any,
       expose: %i(access-token expiry token-type uid client),
       methods: %i(get post put patch delete options head),
       credentials: true
  end
end

KnotenJS

In Node.js sieht dies folgendermaßen aus.

app.all(‘*’, (req, res, next) => {
  res.header(‘Access-Control-Allow-Origin’, ‘*’);
  res.header(‘Access-Control-Allow-Methods’, ‘PUT, GET, POST, DELETE, PATCH, OPTIONS HEAD’);
  res.header(‘Access-Control-Allow-Headers’, ‘*’);
  res.header(‘Access-Control-Allow-Credentials’, true);
  next();
});

Im Code-Snippet richten wir den Ursprung, die Methoden, Header und Anmeldeinformationen ein, denen der Zugriff auf die auf unserem Server verfügbaren Ressourcen gestattet werden soll. Informationen zur Implementierung in Apache oder Nginx finden Sie hier Guide.

Conclusion

CORS lockert die Richtlinie, sodass Ihr Browser auf die gewünschten Ressourcen zugreifen kann. Wenn Sie wissen, was es ist, warum es wichtig ist und wie Sie es einrichten, können Sie herausfinden, auf welche Probleme Sie beim Erstellen Ihrer Webanwendungen stoßen können.