CORS on asset hostnames and HTTPS-only GraphQL API from December 7, 2026

CORS headers on asset hostnames

Asset responses on a.storyblok.com, a-us.storyblok.com, a-ap.storyblok.com and a-ca.storyblok.com will include Access-Control-Allow-Origin: *, and the CDN will answer CORS preflight (OPTIONS) requests. You can then load assets with fetch(), canvas, WebGL or web fonts from any website, without switching to an a2 hostname. URLs, caching and the Image Service stay the same.

Who needs to act

• You load assets with <img>, <video> or plain links: nothing to do.
• A proxy, CDN or edge function in front of your asset URLs adds its own Access-Control-Allow-Origin header: remove it for asset URLs, or make it replace the header instead of adding a second one. Browsers reject responses with two values.
• Your proxy handles OPTIONS requests to asset URLs itself: check that it accepts the CDN's preflight response.
• Your code or tests check the exact asset response headers: test against the new headers before December 7, 2026.

How to check

Request an asset through your proxy:

curl -sI -H "Origin: <https://example.com>" "https://<your-proxy-host>/f/<asset-path>" | grep -i access-control

If this prints a value, your proxy adds the header itself. After the change, the CDN returns access-control-allow-origin: * and access-control-expose-headers: *. The a2 hostnames already do, so you can test against them today.

HTTPS only for the GraphQL API

From December 7, 2026, plain http:// requests to the GraphQL API (gapi.storyblok.com, gapi-us, gapi-ap and gapi-ca) will be redirected to https://.

• GET requests that follow redirects keep working.
• POST requests, which most GraphQL clients use, may fail, because many HTTP clients don't follow a redirect for POST.
• Apps running on HTTPS pages aren't affected, because they can't call http:// anyway.

If any of your servers, scripts or integrations call the API over http://, switch them to https:// before December 7, 2026.