Cross-Origin Resource Sharing (CORS)

Je browser gedraagt zich als portier

Het internet is gebouwd op vertrouwen, maar dat vertrouwen heeft grenzen. Zonder beperkingen zou elke willekeurige website jouw data kunnen opvragen bij bijvoorbeeld je bank of je e-mailprovider. Om dat tegen te gaan, hebben browsers het same-origin policy ingevoerd: een webpagina mag alleen communiceren met bronnen van hetzelfde domein.

Maar… in de praktijk willen we juist vaak communiceren met andere domeinen, bijvoorbeeld een front-end op domein A die data ophaalt van een API op domein B. Dat is precies waar CORS om de hoek komt kijken.

Wat gebeurt er achter de schermen?

Als je browser een cross-origin verzoek doet, kijkt de server waar het verzoek naartoe gaat of dat is toegestaan. Dat doet hij via de CORS-header Access-Control-Allow-Origin. Staat daar jouw domein tussen? Dan wordt de data netjes doorgestuurd. Staat het er niet tussen? Dan wordt het verzoek geblokkeerd.

Voor simpele GET-verzoeken werkt dit vrij soepel. Maar bij bijvoorbeeld POST-verzoeken of custom headers voert de browser eerst een “preflight request” uit: een soort test om te checken of het verzoek is toegestaan. Pas bij goedkeuring volgt het echte verzoek.

Help! Mijn API mag er niet in

CORS-fouten zijn een klassieker bij webdevelopment. Je code is goed, je API werkt, maar de browser houdt je tegen. De oplossing ligt meestal bij de server: die moet expliciet toestaan dat jouw domein verzoeken mag doen. Dat kan door:

• Een wildcard (*) toe te staan (alleen veilig bij publieke data)
• Specifieke domeinen whitelisten via Access-Control-Allow-Origin
• CORS correct configureren in frameworks zoals Express.js, Laravel of Django

Let op: voor gevoelige data is het belangrijk om alleen vertrouwde domeinen toegang te geven.