Closed Rabadash8820 closed 2 years ago
So upon further research, there are really like 3 ways we could set up CORS on the redirect CDN:
SECURITY_HEADERS
). This would have the same effect as 1.Access-Control-Allow-Origin
, to responses (e.g., the CORS_ALLOW_ALL_ORIGINS
policy). This would allow the listed origins (or all origins if the value of the header is *
) to send XHR requests.From reading around, it seems like CORS is something you only enable (you only add the CORS headers) when you need it. Otherwise, browsers' same-origin policy is the logical default behavior. I looked at a couple e-commerce websites and blogs, and none of them include ACCESS_CONTROL_*
headers. In fact, it seems like most origins don't, unless they're literally "public APIs". Thus, we should stick with the default CloudFront behavior of not adding any CORS headers, either by setting no response header policy, or setting one that does not add CORS headers.
As for the main domain and main redirect domain, which send requests to GitHub Page's servers, we are bound by whatever headers those servers set. Unfortunately, GitHub Pages does add CORS headers (verified by running curl -I https://www.derploid.com
). Presumably they did this to allow users to host any kind of site or API on GitHub Pages. This isn't a huge deal for us, since our site doesn't expose any endpoints for XHR requests anyway; all that other origins can do is request our static pages; no security risks. 🤷♂️
So yeah, this Issue is basically done just by keeping the CF defaults. Closing now...
CORS (Cross-Origin Request Security) provides some benefits related to protecting domains from unauthorized requests. I don't quite understand the details, but I think it could be good to add. We can tell CloudFront to add CORS headers to responses using one of the managed response policies.