Wat is Cross Origin Resource Sharing

Mocht je een web applicatie hebben gebouwd, dan heb je er vast al eens te maken mee gehad: cross origin resource sharing. Maar wat is dit nu precies?

Cross Origin Resource Sharing, of CORS in het kort, is een mechanisme dat gebruik maakt van HTTP headers om een browser te laten weten dat een web applicatie die op domein A draait, toestemming heeft om toegang te krijgen tot geselecteerde bronnen en informatie van een server die op domein B draait. Een web applicatie voert een Cross Origin HTTP-verzoek uit wanneer het informatie aanvraagt die een andere oorsprong (domein, protocol en poort) heeft dan zijn eigen oorsprong.

Een voorbeeld van een hierboven geschreven HTTP-verzoek is Javascript vanuit een web applicatie die draait op https://domein-a.nl welke via een JSON-verzoek informatie ophaalt vanaf https://api.domein-b.nl.

Je kunt je voorstellen dat het gebruik van CORS risico’s met zich meebrengt. Browsers blokkeren daarom HTTP-verzoeken vanuit een andere oorsprong (domein, protocol of poort). De web toepassing kan dan alleen informatie verzoeken van bijv. API’s die van dezelfde oorsprong zijn. Mocht de webapplicatie toch informatie aan willen vragen van een API die niet van dezelfde oorsprong is, dan moeten de juiste CORS headers meegestuurd worden.

CORS werkt aan de hand van een aantal headers die aan het HTTP-verzoek worden toegevoegd waarmee servers aan kunnen geven welke oorsprongen er allemaal toestemming hebben om informatie te verkrijgen met behulp van een browser.

Één van de header is Access-Control-Allow-Origin. Deze header wordt gebruik door servers om aan te geven welke oorsprongen er allemaal toestemming hebben om bijvoorbeeld informatie op te vragen. Vaak is de waarde van deze header die wordt teruggeven door de server een ‘*’, wat betekent dat de server informatie deelt met alle oorsprongen. Een andere mogelijkheid is dat deze header een domeinnaam bevat van het domein waarmee de server informatie deelt.

Daarnaast is het vereist dat bij HTTP-verzoeken die anders zijn dan een GET, er eerst een preflight van het verzoek wordt verstuurd en deze wordt dan nagekeken door de server. Een preflight wordt verstuurd vóórdat het eigenlijke verzoek wordt verstuurd. De server kan dan het preflight verzoek verwerken, checken van welke methoden er eigenlijk gebruik gemaakt wordt (GET, POST, etc.). De preflight maakt gebruik van de OPTIONS header waarin aangeven wordt om wat voor verzoek het gaat, bijv. een DELETE. Zo kan de server beoordelen of een verzoek veilig is of niet en een verzoek blokkeren waar nodig.