1

I know if Access-Control-Allow-Origin is a wildcard *, script X cannot be accessed from an origin Y when the request's credentials mode is 'include'. Fair enough!

Normally, when we have Nginx, we solve this by something like:

    add_header 'Access-Control-Allow-Origin' $http_origin;

From what I understood, seems like there is no $http_origin equivalent in Google Cloud storage (or is there?).

So, if the resource is in Google Cloud storage, I don't know how can I adjust the CORS setting to do the same.

I currently do the following:

$ printf '[{"origin": ["*"],"responseHeader": ["*"],"method":
    ["GET","POST","HEAD"],"maxAgeSeconds": 900}]' > cors.json
$ gsutil cors set cors.json gs://mybucket
$ gsutil -m rsync -a public-read ./myfolder/ gs://mybucket/myfolder/

The error I received, as I said, is this:

Access to script at 'https://storage.googleapis.com/mybucket/myfolder/myfile.js' from origin 'https://www.whatever.com' has been blocked by CORS policy: The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when the request's credentials mode is 'include'.

My question is specifically about Google Cloud storage settings: how can I fix this issue for static files I'm uploading to Google Cloud storage?

Update 1: This resource is a public url and can be called from any HTTPS website, even the ones that we don't explicitly know about.

Here is the screenshot of the error: enter image description here

Update 2:

Here is the request cURL I copy pasted from network tab in Chrome:

curl 'https://storage.googleapis.com/whatever/whatever/file.js' \
  -H 'authority: storage.googleapis.com' \
  -H 'accept: */*' \
  -H 'accept-language: en-US,en;q=0.9' \
  -H 'cache-control: no-cache' \
  -H 'origin: https://www.example.com' \
  -H 'pragma: no-cache' \
  -H 'referer: https://www.example.com/' \
  -H 'sec-ch-ua: "Google Chrome";v="107", "Chromium";v="107", "Not=A?Brand";v="24"' \
  -H 'sec-ch-ua-mobile: ?0' \
  -H 'sec-ch-ua-platform: "macOS"' \
  -H 'sec-fetch-dest: script' \
  -H 'sec-fetch-mode: cors' \
  -H 'sec-fetch-site: cross-site' \
  -H 'user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/107.0.0.0 Safari/537.36' \
  --compressed
oguz ismail
  • 1
  • 16
  • 47
  • 69
Michel Gokan Khan
  • 2,525
  • 3
  • 30
  • 54
  • Using the wildcard allows anyone to access the endpoint, which is no protection at all. Specify the origin(s) that are allowed access in this format: `https://www.example.com`. `$http_origin` is the domain name your web server is configured for the current request. Even with CORS set up correctly, anyone using CURL can still access the resource. Make sure you understand what you are configuring, why, and the side effects. – John Hanley Dec 08 '22 at 01:49
  • Is this $http_origin supported in cors.json file format? If not, what's the equivalient? @JohnHanley – Michel Gokan Khan Dec 08 '22 at 08:37
  • I do not understand what you asked. `$http_origin` is an Nginx feature. – John Hanley Dec 08 '22 at 08:41
  • @JohnHanley I know. Is there any equivalent way in Google Cloud storage to do the same? I need to access static/asset files from other https web pages, but currently I'm getting the CORS policy error. – Michel Gokan Khan Dec 08 '22 at 08:44
  • You should know your website's domain (the origin). That is what you use. – John Hanley Dec 08 '22 at 09:06
  • @JohnHanley But this is a public resource, I have no control over who is using it and anyone should be able to have access to it and embed/call it from their website. – Michel Gokan Khan Dec 08 '22 at 09:09
  • Then remove CORS. Google Cloud Storage does **not** require you to enable CORS. – John Hanley Dec 08 '22 at 09:11
  • @JohnHanley I originally didn't have CORS settings, and I was getting "the resouce has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource." ... that's why I added it. – Michel Gokan Khan Dec 08 '22 at 09:14
  • You should clearly specify the requirements in your question. For example, that error message comes from a web browser when making cross-origin requests. Your question said `script`. Yes, scripts run in a browser, but that distinction is very important. If you do not want that error you have several options: a) set up a domain name for Cloud Storage so that the same domain (origin) is used; b) set up CORS; c) serve the objects via your web server. – John Hanley Dec 08 '22 at 09:21
  • Note, one additional item about the error message. Are you including credentials in the request? Again you do not specify that in your question. Reread the error message to understand what it is telling you. – John Hanley Dec 08 '22 at 09:23
  • Thanks @JohnHanley I've updated my question with a screenshot attached from the browser and additional info. Option A, not sure how setting up a domain name for Google Cloud storage bucket would solve the issue? The url is not changing at the moment, it's a fixed url starting with "https://storage.googleapis.com/bucketname/foldername/filename.js" - For option B, What kind of CORS setting, the wildcard is not working - Option C we want to avoid due to massive cost --- I don't include credentials in the request, just the public url to the resource in the Google Cloud storage – Michel Gokan Khan Dec 08 '22 at 09:35
  • Show the HTTP request and all headers. – John Hanley Dec 08 '22 at 09:48
  • Please look at this question and the accepted answer: https://stackoverflow.com/questions/42803394/cors-credentials-mode-is-include – John Hanley Dec 08 '22 at 09:50
  • @JohnHanley Thanks, I just added the full request as a curl command in the question. – Michel Gokan Khan Dec 08 '22 at 10:53
  • @MichelGokanKhan How are you requesting that `.js` file? If it's loaded by a `script` element as a (non-JS module) subresource, it should not give rise to a CORS request. Besides, allowing any origin with credentials is insecure. – jub0bs Dec 08 '22 at 11:18
  • @jub0bs I think I found what's the problem. There was a hidden script somewhere that was setting crossorigin to use-credentials....changing that to anonymous solved the issue. And yes, I was generating the – Michel Gokan Khan Dec 08 '22 at 11:31
  • @JohnHanley I think the problem is solved, thanks to your help. Check my previous comment. – Michel Gokan Khan Dec 08 '22 at 11:31

1 Answers1

0

The problem was the crossorigin settings of the generated tag. The problem was resolved after setting it to anynomous.

Michel Gokan Khan
  • 2,525
  • 3
  • 30
  • 54