CORS and allowed domains
What the domain allowlist does, and the thing it deliberately does not do.
Examples use a fictional festival, summer-fest. Sign in at events.grofomo.com and they switch to your own events.
Organisers keep a list of domains allowed to call their feeds from a browser. A request whose Origin is not on that list is refused with 403 origin_not_allowed.
Entries
https://www.yourfestival.com— exact originhttps://*.yourfestival.com— any subdomain, same scheme*— any origin (an explicit opt-in)
The header we echo back is always the concrete request origin, never the pattern, so credential-less cross-origin reads work in every browser.
What it does
It stops a lifted publishable key from working somewhere else. Your key is in your page source by design; the allowlist means someone who copies it still cannot use it to power their own site's festival listing from a browser.
What it does not do
CORS is not access control. It is a rule browsers agree to follow. curl does not follow it, and neither does anything else outside a browser:
# No Origin header, so no CORS decision to make.
curl 'https://api.grofomo.com/v1/events/summer-fest/lineup?surface=web'That is not a hole — it is what CORS is. It is also the reason API keys exist: the allowlist is the second layer, and the key is the first. An organiser who wants their feeds genuinely closed sets key_required; the allowlist alone would only inconvenience browsers.
Server-side calls
A server sends no Origin header, so the allowlist never applies to it. If your site fetches during build or render, allowed domains are irrelevant to you — only your key matters.
Preflight
OPTIONS preflight requests are never gated. A browser must be able to complete the handshake before it can send the credential the handshake is about.