Find out whether a browser would let your code read an API response, and exactly which check blocks it. Real preflight and request diagnostics, not a header dump.
Eén origin per regel, maximaal tien. Handig om te controleren of lokaal, staging en productie allemaal op de allowlist staan. De resultaten verschijnen als tabel op het tabblad Headers.
Deze verzoeken worden vanaf servers van POLPROG naar het endpoint gestuurd dat u opgeeft, omdat een browser deze diagnose niet op zichzelf kan uitvoeren: CORS is nu juist wat dat zou blokkeren. Er wordt geen cookie van u doorgestuurd, er wordt nooit een verzoekbody meegestuurd, responsbodies worden weggegooid, en er wordt niets bewaard zodra het rapport bij u is.
Een regel van de browser, niet van de server. Wanneer JavaScript op de ene origin een resource op een andere opvraagt, stuurt de browser het verzoek wel, maar geeft hij de respons niet aan uw code, tenzij de server in zijn responsheaders zegt dat de vragende origin die mag lezen. Cross-Origin Resource Sharing is de verzameling headers waarmee dat wordt gezegd.
Als een verzoek werkt in curl, Postman, Insomnia of vanaf uw eigen backend, zegt dat niets over de vraag of JavaScript in een browser het kan lezen. Die clients passen helemaal geen CORS-regels toe. De server gedraagt zich meestal in beide gevallen identiek; het verschil zit volledig in wat de aanroeper met de respons doet.
Voor alles behalve de eenvoudigste verzoeken stuurt de browser eerst een OPTIONS-verzoek met de vraag of het echte verzoek is toegestaan. Dat draagt Origin, Access-Control-Request-Method en zo nodig Access-Control-Request-Headers mee. Als het antwoord het verzoek niet toestaat, wordt het echte verzoek nooit verstuurd, dus het endpoint ziet het nooit en in uw serverlogs staat niets.
Een verzoek is alleen eenvoudig als de methode GET, HEAD of POST is en elke header die het instelt op de CORS-safelist staat: Accept, Accept-Language, Content-Language, Content-Type en Range. De waarde telt ook mee. Content-Type blijft alleen safelisted bij application/x-www-form-urlencoded, multipart/form-data en text/plain.
Het staat niet in de lijst van drie safelisted contenttypes. Dat is de hele reden. Een POST met een JSON-body is een verzoek met preflight, en daarom levert het toevoegen van een JSON-API aan een bestaande pagina ineens een OPTIONS-verzoek op dat niemand heeft geschreven, plus fouten uit een route die alleen POST afhandelt.
Ofwel één enkele origin, ofwel *. Nooit een lijst, nooit een waarde met een pad, nooit een wildcard binnen een hostnaam. De vergelijking met de vragende origin is exact, dus een afsluitende schuine streep, een uitgeschreven standaardpoort of http waar het verzoek https gebruikte gaan allemaal mis terwijl ze er voor een mens identiek uitzien.
Nodig wanneer het verzoek cookies of HTTP-authenticatie meestuurt. De enige waarde die wordt geaccepteerd is de exacte kleine-letterreeks true. Aan een verzoek met credentials kan Access-Control-Allow-Origin: * evenmin voldoen, en voor datzelfde verzoek is een asterisk in Allow-Methods, Allow-Headers of Expose-Headers geen wildcard meer maar een letterlijke naam.
Als de server de waarde van Allow-Origin uit het binnenkomende verzoek haalt, hangt de respons af van de Origin-header en moet elke gedeelde cache dat weten. Zonder Vary: Origin kan een CDN of reverse proxy een respons opslaan die de ene origin noemt en die aan een andere serveren, waardoor verzoeken mislukken om redenen die nooit in de applicatie zichtbaar worden.
Een cross-origin respons stelt maar zeven headers beschikbaar aan script: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified en Pragma. Al het andere, inclusief uw eigen X-headers en Location, leest als null tenzij het in Access-Control-Expose-Headers wordt genoemd. Die header gaat over de respons en staat los van Allow-Headers, dat over het verzoek gaat.
Het bepaalt welke origins een respons in een browser mogen lezen. Het bepaalt niet wie een endpoint mag aanroepen, het verleent geen rechten, en het stopt cross-site request forgery niet: een CSRF-aanval hoeft de respons niet te lezen, dus een strikt CORS-beleid laat die onaangeroerd. Houd authenticatie, autorisatie en CSRF-tokens precies zoals ze waren.
Elk oordeel hier komt uit een echte uitwisseling met het endpoint dat u hebt opgegeven, getoetst aan de regels van de Fetch standard die een browser toepast. Het beschrijft het endpoint zoals dat op dat moment antwoordde aan de infrastructuur van POLPROG: een server die zijn respons laat afhangen van netwerk, regio of authenticatie kan uw browser anders antwoorden. Tijden worden vanaf onze infrastructuur gemeten en zijn geen meting in een browser. Het testen van het echte verzoek staat standaard uit voor methoden die gegevens kunnen wijzigen, en er wordt nooit een verzoekbody meegestuurd.
Omdat alleen browsers CORS afdwingen en niets anders. Postman, curl, Insomnia en uw eigen backend passen helemaal geen CORS-regels toe, dus zij krijgen de respons ongeacht welke headers die draagt. De server gedraagt zich meestal in beide gevallen identiek. Het verschil zit volledig in wat de aanroeper met het antwoord doet, en een browser geeft het niet aan uw JavaScript tenzij de respons zegt dat die origin het mag lezen.
Een OPTIONS-verzoek dat de browser vóór het echte verzoek stuurt, om te vragen of dat echte verzoek is toegestaan. Het draagt Origin, Access-Control-Request-Method en zo nodig Access-Control-Request-Headers mee. Als het antwoord het verzoek niet toestaat, wordt het echte verzoek nooit verstuurd, dus uw endpoint ziet het nooit en in uw serverlogs staat niets. Alleen verzoeken die niet eenvoudig zijn krijgen een preflight.
Content-Type staat alleen op de CORS-safelist bij application/x-www-form-urlencoded, multipart/form-data en text/plain. Alleen die drie. Een JSON-body zet het verzoek buiten de safelist, dus de browser kondigt het vooraf aan. Daarom levert het toevoegen van een JSON-API aan een bestaande pagina ineens een OPTIONS-verzoek op dat niemand heeft geschreven.
Omdat een respons die aan een ingelogde gebruiker vasthangt niet leesbaar mag zijn voor elke site die deze gebruiker bezoekt. Als een verzoek cookies of HTTP-authenticatie meestuurt, moet de server de origin noemen die hij vertrouwt, en een browser wijst een wildcard zonder meer af, ook naast Access-Control-Allow-Credentials: true. Hetzelfde geldt voor een asterisk in Allow-Methods, Allow-Headers en Expose-Headers: bij een verzoek met credentials wordt elk daarvan gelezen als een letterlijke headernaam en niet als een wildcard.
Nee. CORS bepaalt welke origins een respons binnen een browser mogen lezen. Het is geen authenticatie, het verleent geen rechten, en het stopt cross-site request forgery niet, omdat een CSRF-aanval de respons niet hoeft te lezen. Elke client die geen browser is negeert het volledig. Houd uw authenticatie, uw autorisatiecontroles en uw CSRF-tokens precies zoals ze zijn.
Van servers van POLPROG naar het endpoint dat u opgeeft, omdat een browser deze diagnose niet op zichzelf kan uitvoeren: CORS is nu juist wat dat zou blokkeren. Alleen de headers die voor de analyse nodig zijn worden verstuurd, er wordt geen cookie van u doorgestuurd, er wordt nooit een verzoekbody meegestuurd, en responsbodies worden weggegooid. Er wordt niets bewaard zodra het rapport bij u is, en waarden van gevoelige headers zoals Authorization worden nooit getoond of geëxporteerd.
Een organisatie vraagt vaak om “één security scanner”, maar het echte probleem bestaat uit meerdere lagen:
HTTP-beveiligingsheaders laten een server regels aan de browser doorgeven voor scripts, frames, apparaatfuncties, referrer-informatie, MIME-typen en HTTPS. Een passende configuratie beperkt de gevolgen van onder meer XSS, clickjacking, MIME confusion, XS-Leaks en ongewenste cross-origin embedding.
Een goede website-audit is geen losse Lighthouse-score en ook geen lijst met tientallen automatische waarschuwingen. De audit moet vier vragen beantwoorden: kan een zoekmachine de website correct vinden en begrijpen, kan een gebruiker zijn taak efficiënt afronden, is de website snel genoeg en stelt de website de eigenaar of bezoekers bloot aan onnodige risico’s?
Wij bouwen maatwerksoftware en oplossingen afgestemd op jouw wensen.