Add CORS header to responses
See original GitHub issueGitHub Pages adds access-control-allow-origin: *
to all pages, so for static content hosted by Cloudflare Workers Sites, I’m guessing it should be safe to do the same.
Issue Analytics
- State:
- Created 3 years ago
- Reactions:3
- Comments:7 (4 by maintainers)
Top Results From Across the Web
Cross-Origin Resource Sharing (CORS) - MDN Web Docs
Cross-Origin Resource Sharing (CORS) is an HTTP-header based mechanism that allows a server to indicate any origins (domain, scheme, ...
Read more >CORS and the Access-Control-Allow-Origin response header
The Access-Control-Allow-Origin header is included in the response from one website to a request originating from another website, and identifies the permitted ...
Read more >How does the 'Access-Control-Allow-Origin' header work?
The Access-Control-Allow-Origin response header indicates whether the response can be shared with requesting code from ...
Read more >Add a cross-origin resource sharing ... - AWS Documentation
The following example function adds an Access-Control-Allow-Origin HTTP header to the response if the response doesn't already contain this header.
Read more >The Access-Control-Allow-Origin Header Explained
Access-Control-Allow-Origin is a CORS header. CORS, or Cross Origin Resource Sharing, is a mechanism for browsers to let a site running at ...
Read more >
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free
Top Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
I think adding
Acess-Control-Allow-Origin: *
to assets returned bykv-asset-handler
would be totally fine, but should definitely be a SemVer major change. For static assets, I can’t think of any security issues doing this, but would encourage anyone with more info to correct me.As others have mentioned, Workers are used for other things like APIs where you may very much want to restrict your CORS configuration, but for these use-cases you wouldn’t use
kv-asset-handler
to serve an asset, and would be manually controlling this anyway.My concern with making this an optional configuration option would be for an ever-growing scope with headers: which headers do we decide should be first-party configuration options (security ones?), and which should be left to the user to maintain and configure? It’s pretty trivial to override headers set on the
Response
anyway, but this definitely adds a level of ambiguity.As a comparison, Netlify seems to handle this with a
_headers
file: https://docs.netlify.com/routing/headers/. Something like this may make sense for Pages, butkv-asset-handler
is definitely more code than config driven.Hi Aaron, thanks for your input. I would love to hear why you think that CORS should be disabled by default. Do you have an example of static content that would be unsafe to attach the
access-control-allow-origin
header onto? You’re totally correct in saying that it’s easy to add yourself (that’s what I’ve done in the interim), but my thinking is that Workers Sites is very similar to GitHub Pages which do add that header by default.For anyone else looking to add the header manually, in your
workers-site/index.js
,handleEvent
function, you just need to grab the response fromgetAssetFromKV
and inject the header: