[4.0.0-beta.3] webSecurity in webPreferences ignored (CORB)

[ghost]

• Output of node_modules/.bin/electron --version: v4.0.0-beta.3
• Operating System (Platform and Version): Windows 10
• Output of node_modules/.bin/electron --version on last known working Electron version (if applicable): v3.0.4

Expected Behavior
With electron 3, I could pass webPreferences: {webwebSecurity: false} to the BrowserWindow constructor (the equivalent of the --disable-web-security Chrome command line argument) which would disable CORB (effectively allowing cross-origin requests).

Actual behavior
CORB is still doing its thing (ignoring the {webwebSecurity: false} option; I see entries like these in the console:
Cross-Origin Read Blocking (CORB) blocked cross-origin response <URL> with MIME type application/json. See <URL> for more details.

To Reproduce
Make a request (using fetch or xhr) to a file on a different domain.
Example repo:

git clone  https://github.com/IAmPicard/electron-cors-repro
npm install
npm run start

[blackknifes]

@MarshallOfSound
The bug also is exists on version 3.x.

[MarshallOfSound]

@blackknifes That directly contradicts the statement made in the original issue

With electron 3, I could pass webPreferences: {webwebSecurity: false} to the BrowserWindow constructor (the equivalent of the --disable-web-security Chrome command line argument) which would disable CORB (effectively allowing cross-origin requests).

@IAmPicard Can you confirm v3 works as expected?

[ghost]

Yes, everything worked as expected ever since I started using it (back in the 1.8 days) up-to the latest available 3.0 (3.0.4).

[nornagon]

Is it possible you could put together a small repro case (perhaps with https://github.com/electron/fiddle)? I'm not sure exactly how to trigger CORB and I'd like to make sure I'm testing exactly what you're seeing.

[blackknifes]

@IAmPicard
When I started with vue + vuex + webpack + webpack-hot-middleware, It throw cors error.Of course,I have setted webSecurity to false.

[ghost]

I uploaded a small repro case here: https://github.com/IAmPicard/electron-cors-repro.

I tried electron-fiddle, but it looks like the issue doesn't repro when using the "file://" protocol, it needs a local server (http://localhost) such as webpack-dev-server to repro.

If you run the repro as-is, the app will load without errors; after you upgrade the electron from 3.0.4 to 4.0.0-beta.3, the app will error out with CORB.

[blackknifes]

@IAmPicard
The project worked as expected on version v2.x, but throw errro on version v3.x.
Why it throw error on version v3.x?

[ghost]

@blackknifes I don't believe your issue is related to CORS, it's most likely same-origin, and unrelated to the issue described here (which is CORS-related, and specific to 4.0.0).

[blackknifes]

@IAmPicard Ok, I will create new issue.

[nornagon]

Confirmed, that repro case behaves differently on 3.0.4 and 4.0.0-beta3.

[aokihu]

I have met the same problem, upgrade from 3.0.5 to 4.0-beta, It's good at 3.0.5
My platform is macOS

[BinaryMuse]

It looks like CrossOriginReadBlocking::ResponseAnalyzer::ShouldAllow() is returning false here due to should_block_based_on_headers_ being set to kBlock.

We were unable in the time we had today to determine if there was a way to affect this behavior based on the webSecurity option; however, on master, Chromium includes this code in CrossSiteDocumentResourceHandler::ShouldBlockBasedOnHeaders (which is what creates and uses the ResponseAnalyzer):

  // --disable-web-security also disables Cross-Origin Read Blocking (CORB).
  if (base::CommandLine::ForCurrentProcess()->HasSwitch(
          switches::kDisableWebSecurity))
    return false;

Unclear to me if this is the best way forward, however passing --disable-web-security on Electron built from master after including the above snippet does seem to resolve this issue.

[BinaryMuse]

After chatting with @deepak1556, #15618 should allow us to tackle this in a good way.

[aokihu]

Do you fix the problem now? I test beta5, and it does not work well

[aokihu]

If the problem can not be fixed, the project is useless from 4.0
An isolate application can not in the same URL domain, so how we communicate with server?

[deepak1556]

Although the issue is fixed in #15737 , I would suggest not to disable web security in production. Here are some good docs about CORB checks and how to fix it in your application, from the chrome team https://developers.google.com/web/updates/2018/07/site-isolation

For in-depth understanding of CORB https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md

[ghost]

Although the issue is fixed in #15737 , I would suggest not to disable web security in production.

The alternatives are to allow all origins on the server (Access-Control-Allow-Origin: *), or to move all such network calls down into node and IPC all the data, right?

Or am I missing another alternative that allows us to do fetch() calls from origin file:// against a CORS-enabled server (that doesn't allow file:// for obvious reasons)? Perhaps a way to modify the (otherwise unmodifiable) origin header on requests?

[deepak1556]

to move all such network calls down into node

You can use the net module along with stream protocol

Or am I missing another alternative that allows us to do fetch() calls from origin file:// against a CORS-enabled server

Yeah I would advice against relying on file for these scenarios

[ckerr]

Still needs to be backported to 4-0-x

[ghost]

I can confirm the issue is fixed in v4.0.0-beta.8 ; I'm experiencing other unrelated crashes with v4.0.0-beta.8, but this particular regression no longer repros.

Thank you!

[deepak1556]

@IAmPicard thanks for confirming.