Wat is het probleem dat CORS probeert op te lossen?

Ik heb gelezen over CORSen hoe het werkt, maar ik vind veel dingen verwarrend. Er zijn bijvoorbeeld veel details over zaken als

Gebruiker Joegebruikt browser BrowserXom gegevens op te halen van site.com,
die op zijn beurt een verzoek stuurt naar spot.com. Om dit toe te staan, heeft spot
speciale headers… yada yada yada

Zonder veel achtergrond begrijp ik niet waarom websites geen verzoeken van sommige plaatsen toelaten. Ik bedoel, ze bestaan ​​om te reageren op verzoeken, nietwaar? Waarom zouden verzoeken van bepaalde mensen niet worden toegestaan?

Ik zou een mooie uitleg (of een link naar een) van het probleem dat CORSmoet oplossen, zeer op prijs stellen.

Dus de vraag is,

Wat is het probleem dat CORSoplost?


Antwoord 1, autoriteit 100%

Het standaardgedrag van webbrowsers die verzoeken van een pagina starten via JavaScript (AKa AJAX) is dat ze het beleid van dezelfde oorsprong. Dit betekent dat verzoeken alleen via AJAX naar hetzelfde domein (of subdomein) kunnen worden gedaan. Verzoeken aan een geheel ander domein zullen mislukken.

Deze beperking bestaat omdat verzoeken die door uw browser op andere domeinen worden gedaan, uw cookiesmet zich meebrengen, wat vaak betekent dat u bent ingelogd op de andere site. Dus, zonder dezelfde oorsprong, zou elke siteJavaScript kunnen hosten dat logout op bijvoorbeeld stackoverflow.com aanroept, en het zou u uitloggen. Stel je nu de complicaties voor als we het hebben over sociale netwerken, banksites, enz.

Dus alle browsers beperken gewoon op scripts gebaseerde netwerkaanroepen tot hun eigen domein om het eenvoudig en veilig te maken.

Site X op www.x.com kan geen AJAX-verzoeken doen aan site Y op www.y.com, alleen aan *.x.com

Er zijn enkele bekende tijdelijke oplossingen (zoals JSONP die geen cookies in het verzoek opneemt), maar dit is geen permanente oplossing.

CORSstaat deze domeinoverschrijdende verzoeken toe, maar alleen wanneer elke kant kiest voor CORS-ondersteuning.


Antwoord 2, autoriteit 73%

Laten we het eerst hebben over hetzelfde oorsprongsbeleid. Ik citeer uit een eerder antwoord van mij:

Het beleid van dezelfde oorsprong is uitgevonden omdat het voorkomt dat code van de ene website toegang krijgt tot inloggegevensbeperkte inhoudop een andere site. Ajax-verzoeken worden standaard verzonden met eventuele auth-cookies die door de doelsite zijn verleend.

Stel bijvoorbeeld dat ik per ongeluk http://evil.com/laad, waarmee een verzoek wordt verzonden voor http://mail.google.com/. Als de SOP niet aanwezig was en ik was aangemeld bij Gmail, zou het script op evil.commijn inbox kunnen zien. Als de site op evil.commail.google.comwil laden zonder mijn cookies, kan het gewoon een proxyserver gebruiken; de openbare inhoud van mail.google.comis geen geheim (maar de inhoud van mail.google.combij toegang met mijn cookies iseen geheim).

(Merk op dat ik heb gezegd “inhoud met beperkte gegevens”, maar het kan ook topologie-beperkte inhoudzijn wanneer een website alleen zichtbaar is voor bepaalde IP-adressen.)

Soms is het echter niet evil.comdie probeert in je inbox te gluren. Soms is het gewoon een behulpzame website (bijvoorbeeld http://goodsite.foo) die een openbare API van een andere oorsprong probeert te gebruiken (bijvoorbeeld http://api.example.com). De programmeurs die hard hebben gewerkt aan api.example.comwillendat alle oorsprongen vrij toegang hebben tot de inhoud van hun site. In dat geval kan de API-server op api.example.comCORS-headers gebruiken om goodsite.foo(of een andere verzoekende oorsprong) toegang te geven tot zijn API-antwoorden.

We gaan er dus standaard van uit dat cross-origin toegang een slechte zaak is (denk aan iemand die uw inbox probeert te lezen), maar er zijn gevallen waarin het een goedezaak is (denk aan van een website die toegang probeert te krijgen tot een openbare API). CORS zorgt ervoor dat het goede geval gebeurt wanneer de gevraagde site dat wil.


Antwoord 3, autoriteit 3%

Er zijn veiligheids- en privacyredenen om verzoeken van waar dan ook niet toe te staan. Als je mijn website hebt bezocht, zou je niet willen dat mijn code verzoeken doet aan Facebook, reddit, je bank, eBay, enz. vanuit je browser met behulp van je cookies, toch? Mijn site zou dan namens u berichten kunnen plaatsen, informatie kunnen lezen, bestellingen kunnen plaatsen, enz. Of namens mij met uw rekeningen.

Other episodes