CORS - Ist es eine clientseitige Sache, eine serverseitige Sache oder eine Transportlevel-Sache?

Question

Ich versuche zu verstehen CORS. Aus meiner Sicht ermöglicht es Ihnen, zu beschränken, welche Domänen auf eine Ressource auf Ihrem Server zugreifen können. Dies scheint jedoch nicht die ganze Geschichte zu sein. Zum Beispiel habe ich einen Webservice ohne CORS aktiviert. Ich kann diesen Web-Service nicht über meine Web-Anwendung über jQuery aufrufen (die App läuft auf localhost). Allerdings kann ich den Webservice von Postman aus starten. Also bin ich ein bisschen verwirrt. Gibt es einige zusätzliche Client-Seite Arbeit, die CORS beteiligt?

Answer 1

Es ist ein bisschen von beiden tatsächlich. Ihr Browser verhindert CORS-Anfragen, es sei denn, der Ursprung der Anfrage (d. H. Die Referrer-URL-Domain) befindet sich in einer weißen Liste am Zielort oder das Ziel genehmigt alle Anfragen unabhängig von ihrer Herkunft.

In beiden Fällen wird der erforderliche Header (Access-Control-Allow-Origin) hinzugefügt, der dem Browser mitteilt, dass es in Ordnung ist, die Anfrage an das Ziel zu senden.

Dies stellt sicher, dass Personen mit böswilliger Absicht keine Anforderungen an eine andere Domäne senden können, ohne dass der Benutzer davon weiß.

Answer 2

Der Server ist verantwortlich für die Meldung der zulässigen Ursprünge. Der Webbrowser ist dafür verantwortlich, dass Anforderungen nur von zulässigen Domänen gesendet werden.

Wenn CORS nicht aktiviert ist, verlässt sich ein Browser auf die same origin policy. Der Browser erlaubt nur Anfragen an denselben Host wie der Ursprung. Die gleiche Ursprungspolitik wird angenommen, wenn keine Ursprünge ausdrücklich erlaubt sind.

Ein anderer HTTP-Client als ein Browser verwendet nicht die gleiche Ursprungsrichtlinie oder CORS. Anforderungen, die von diesen anderen HTTP-Clients gestellt werden, haben keinen Ursprung. Sofern die Postman Desktop-Anwendung keinen Browser emuliert, kann sie Anfragen an beliebige URLs stellen.

CORS und die gleiche Ursprungsrichtlinie sind erforderlich, da ein Browser den besuchten Websites nicht implizit vertraut. Sie schützen die Ursprungssite nicht, sie schützen die Site, die die Cross-Ursprungsanforderung erhält.

Ohne diese Richtlinien könnte ein einfaches Skript, das wiederholt eine Website lädt, über Werbenetzwerke oder Skript-Injection verteilt werden und jeder Browser, der das Skript lädt, würde zu einem Denial-of-Service-Angriff auf der Website beitragen. Mit CORS und der gleichen Ursprungsrichtlinie wird ein Browser die Auswirkungen dieses Skripts begrenzen.

CORS mit gutem Beispiel:

Ein Web-Browser eine Seite von www.example.com lädt. Die Seite enthält ein Skript, das eine Anfrage an www.example.org sendet. Der Ursprung der Anfrage ist www.example.com. Der Browser gibt entweder die Anforderung aus oder sendet zuerst eine Anforderung (Preflight-Anforderung). Wenn der Server unter www.example.org eine Anforderung von einem anderen Ursprung als www.example.org empfängt, antwortet er mit einem Antwortheader Access-Control-Allow-Origin, der dem Browser die Herkunft mitteilt, die zulässig ist, um Anforderungen zu stellen. Es kann auch mit anderen Headern wie Access-Control-Allow-Methods und Access-Control-Allow-Headers antworten, die die Arten der zulässigen Anforderungen einschränken können. Wenn dem Browser mitgeteilt wird, welche Ursprünge erlaubt sind, blockiert er zukünftige Anfragen von nicht erlaubten Ursprüngen.