CORS Issue after latest Chrome 85 Update

Question

I am a very new user here so, apologies in advance if I break any rule. Here is the problem I am facing and need suggestions please.

I have a Chrome extension which works with Gmail & consumes APIs from my web server running on nginx through Phusion Passenger server of Rails application.

My Nginx version is nginx version: nginx/1.15.8 and Phusion Passenger version is Phusion Passenger Enterprise 6.0.1

I had the CORS settings in nginx as follows:

####### CORS Management ##########

add_header 'Access-Control-Allow-Origin' 'https://mail.google.com,https://*.gmail.com';

add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS, PUT, DELETE, HEAD';

add_header Referrer-Policy "no-referrer";

add_header Pragma "no-cache";

##################################

This used to work until Chrome 84, however, with the latest update of Chrome 85, it has started throwing CORS errors as follows:

########## Error started appearing in Chrome 85 ############

Access to fetch at 'https://my-site.com/' from origin 'https://mail.google.com' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

##########################################

After this, I updated the CORS settings to wide open as per the suggestions/reference from various sources and blogs and now updated CORS setting looks like this:

UPDATED CORS Settings in Nginx

 location / {

     if ($request_method = 'OPTIONS') {

        add_header 'Access-Control-Allow-Origin' $http_origin always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        
        #
        # Custom headers and headers various browsers *should* be OK with but aren't
        #

        add_header 'Access-Control-Allow-Headers' 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type' always;
        
        #
        # Tell client that this pre-flight info is valid for 20 days
        #

        add_header 'Access-Control-Max-Age' 1728000;
        add_header 'Content-Type' 'text/plain charset=UTF-8' always;
        add_header 'Content-Length' 0 always;

        return 204;
     }

     if ($request_method = 'POST') {

        add_header 'Access-Control-Allow-Origin' $http_origin always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type' always;

     }

     if ($request_method = 'GET') {

        add_header 'Access-Control-Allow-Origin' $http_origin always;
        add_header 'Access-Control-Allow-Credentials' 'true' always;
        add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS' always;
        add_header 'Access-Control-Allow-Headers' 'DNT,X-Mx-ReqToken,Keep-Alive,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type' always;

     }

}

############################################

After updating this setting in Nginx, the CORS error has gone but now I am getting 401 Unauthorized error from server when the extension makes API call.

I tried tweaking all the methods but couldn't fix it up. Is there something which I am missing or doing differently?

Please help!

Answer 1

Isn't that the effect of this spec change?

Changes to Cross-Origin Requests in Chrome Extension Content Scripts https://www.chromium.org/Home/chromium-security/extension-content-script-fetches

Answer 2

I had the same problem. My solution was (as described in the link above) to move the Http-Requests into the background content script.You need to send a message to the background script and perform the request from there.

On receiving the response you need to send a message to the content script where you can handle the response data.

ContentPage                  BackgorundPage
          -- RequestData -->
                              Initialize the request and return to the content script
.... some time later....
                              Callback of HttpRequest is finished
         <-- handleResponse--  (In callback handler)

Content Script:

var msg = new Object();
msg.message = "loadOrders";
chrome.runtime.sendMessage(msg);

Background-Script:

chrome.runtime.onMessage.addListener(
function (msg, sender, sendResponse) {
    if( msgName=="loadOrders") {
        doXHRRequest( function(responseData) {
           sendMessageToActiveTab(responseData);
        });
}

function sendMessageToActiveTab(responseData) {
    var msg = new Object();
    msg.message = "receiveOrders";
    msg.orderList = JSON.parse(Http.responseText);
    chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
        chrome.tabs.sendMessage(tabs[0].id, msg);
    });
}

And last in the content script:

chrome.runtime.onMessage.addListener(function(message, callback) {
  if( message.message == "receiveOrders") {
     receiveOrderList(message.orderList);
  }
  return;
});

Answer 3

as stated in https://developers.google.com/web/updates/2020/07/chrome-85-deps-rems

chrome will Reject insecure SameSite=None cookies

Use of cookies with SameSite set to None without the Secure attribute is no longer supported. Any cookie that requests SameSite=None but is not marked Secure will be rejected. This feature started rolling out to users of Stable Chrome on July 14, 2020. See SameSite Updates for a full timeline and details. Cookies delivered over plaintext channels may be cataloged or modified by network attackers. Requiring secure transport for cookies intended for cross-site usage reduces this risk.