Cross-Origin Read Blocking (Corb)

How to stop CORB from blocking requests to data resources that respond with CORS headers?

Based on the examples in "Changes to Cross-Origin Requests in Chrome Extension Content Scripts", I replaced all invocations of fetch with a new method fetchResource, that has a similar API, but delegates the fetch call to the background page:

// contentScript.js
function fetchResource(input, init) {
  return new Promise((resolve, reject) => {
    chrome.runtime.sendMessage({input, init}, messageResponse => {
      const [response, error] = messageResponse;
      if (response === null) {
        reject(error);
      } else {
        // Use undefined on a 204 - No Content
        const body = response.body ? new Blob([response.body]) : undefined;
        resolve(new Response(body, {
          status: response.status,
          statusText: response.statusText,
        }));
      }
    });
  });
}

// background.js
chrome.runtime.onMessage.addListener(function(request, sender, sendResponse) {
  fetch(request.input, request.init).then(function(response) {
    return response.text().then(function(text) {
      sendResponse([{
        body: text,
        status: response.status,
        statusText: response.statusText,
      }, null]);
    });
  }, function(error) {
    sendResponse([null, error]);
  });
  return true;
});

This is the smallest set of changes I was able to make to my app that fixes the issue. (Note, extensions and background pages can only pass JSON-serializable objects between them, so we cannot simply pass the Fetch API Response object from the background page to the extension.)

Background pages are not affected by CORS or CORB, so the browser no longer blocks the responses from the API.

How To Solve This Problem : Cross-Origin Read Blocking (CORB) blocked cross-origin response

I don't consider this an absolute answer because I am also having the same bug on a chrome extension I built. Now, following the suggestion from CORB (Cross Origin Read Blocking) The Chrome team updated the security of the browser in version 73+ which guards against the spectre and meltdown vulnerability.

On this link, they provide the means on how developers should go about fixing errors from this update: https://www.chromium.org/Home/chromium-security/corb-for-developers

The parent resource for this is: https://www.chromestatus.com/feature/5629709824032768 when I find my fix, I'll be updating this post with it.

Cannot see my image because = CORB blocked cross-origin response

As Quentin mentioned it before, you have to find the image URL, not the page URL containing the image URL. You have two options. First, go by yourself, if it's not a dynamic web page, on the Giphy page, and search by yourself the image : .

Else, using XHR or a backend request, perform a regex on the response content to extract the image. For the example :

const regex = /https:\/\/.*giphy.*\/media\/\w+\/giphy.gif\?cid=[a-f0-9]+&rid=giphy\.gif&ct=g/gi

How to avoid Cross-Origin Read Blocking(CORB) in a chrome web extension

See this issue filed by co-founder at Moesif.

https://bugs.chromium.org/p/chromium/issues
https://bugs.chromium.org/p/chromium/issues/detail?id=933893

Based on his discussion with Chronium engineers, basically, you should added extraHeaders
into extra options for when adding listeners, which will pull this trigger closer to the network and inject the headers before CORB gets triggered.

chrome.webRequest.onHeadersReceived.addListener(details => {
  const responseHeaders = details.responseHeaders.map(item => {
    if (item.name.toLowerCase() === 'access-control-allow-origin') {
      item.value = '*'
    }
  })
  return { responseHeaders };
}, {urls: ['<all_urls>']}, ['blocking', 'responseHeaders', 'extraHeaders'])

Btw, a little self promotion here. Why don't you just use our CORS tool,

https://chrome.google.com/webstore/detail/moesif-orign-cors-changer/digfbfaphojjndkpccljibejjbppifbc?hl=en

It is already the most feature complete CORS tool.

---

Related Topics