electron: "Content Security Policy of your site blocks the use of 'eval' in JavaScript"

@Officialstrike This log message is currently expected in development, if you run your packaged app it will not occur

I’ve explained in detail that the code of my first example does in fact not use eval.

I think that is a misunderstanding. Let me rephrase.

Electron warns you that you don’t allow eval and my question is: Why show a warning for that? A strict CSP is not something to warn about, it is desired. Of course a warning should be shown in case a resource could not be loaded due to the strict CSP. But that’s not the case (at least not visibly).

Here’s a minimal example. The index.html is served locally and does not even load a script. Yet, there is this alarming warning at the bottom.

This is the code that injects the CSP in the main file:

session.webRequest.onHeadersReceived((details, callback) => {
    if (details.url.startsWith('devtools://')) {
        return callback({
            responseHeaders: {
                ...details.responseHeaders,
                'Content-Security-Policy': [
                    "default-src 'self' 'unsafe-eval' 'unsafe-inline' data:",
                ].join('; '),
            },
        });
    }
    return callback({
        responseHeaders: {
            ...details.responseHeaders,
            'Content-Security-Policy': [
                "default-src 'self'",
            ].join('; '),
        },
    });
});

Edit: My hunch is that this is a script that Electron injects when loading the URL containing some form of eval. When attempting to load scripts that are actually using eval, the amount of affected resources expands with each resource that contains some eval calls (even if they are not loaded):

(Side note: Interestingly, creating a new WASM instance from a Uint8Array also counts as eval. Which makes sense if you think about it.)

Electron warns you if you use eval.

Beyond the pedagogical issue, and the waste of time for developers encountering this error for the first time, it is generally bad practice to show both real security issues and benign information using similarly styled error messages containing subtle wording. How am I supposed to tell if a warning requires my attention in order to avoid security flaws? Personally, I have already forgotten which message is the one indicating the error and which is the one we are supposed to ignore peacefully.

This warning should not be shown in development either. It’s confusing and will result in wasted time and bad workarounds.

I’m also very confused by this. Electron warns when my CSP is insecure but it also warns when it’s very secure. What is the point of this prominent warning?

@MarshallOfSound can you please clarify why this message is there? Is it a temporary thing that’s supposed to go away at some point? Should we just ignore it? Does it indicate a security problem?

(Side note: Interestingly, creating a new WASM instance from a Uint8Array also counts as eval. Which makes sense if you think about it.)

Yes… but also this is one of the standard ways to instantiate WASM? It is either that or compileStreaming(). And yes, the latter is usually preferred; but there are some situations where it cannot be used.

To the point: I still do not understand if there is any setting in which Electron will not issue some kind of warning about the security policy in effect. Regardless of whether or not your code actually uses eval. IMHO this is very confusing behavior, esp. to newcomers.

I think that is a misunderstanding. Let me rephrase.

Electron warns you that you don’t allow eval and my question is: Why show a warning for that? A strict CSP is not something to warn about, it is desired. Of course a warning should be shown in case a resource could not be loaded due to the strict CSP. But that’s not the case (at least not visibly).

Here’s a minimal example. The index.html is served locally and does not even load a script. Yet, there is this alarming warning at the bottom.

This is the code that injects the CSP in the main file:

session.webRequest.onHeadersReceived((details, callback) => {
    if (details.url.startsWith('devtools://')) {
        return callback({
            responseHeaders: {
                ...details.responseHeaders,
                'Content-Security-Policy': [
                    "default-src 'self' 'unsafe-eval' 'unsafe-inline' data:",
                ].join('; '),
            },
        });
    }
    return callback({
        responseHeaders: {
            ...details.responseHeaders,
            'Content-Security-Policy': [
                "default-src 'self'",
            ].join('; '),
        },
    });
});

Edit: My hunch is that this is a script that Electron injects when loading the URL containing some form of eval. When attempting to load scripts that are actually using eval, the amount of affected resources expands with each resource that contains some eval calls (even if they are not loaded):

(Side note: Interestingly, creating a new WASM instance from a Uint8Array also counts as eval. Which makes sense if you think about it.)

NB: this is being addressed by the Electron security team in PR #30991. 👍

it’s intended to increase the security in electron apps.

It would be meeting its intended purpose if it appeared when the developer actually did something insecure. As it stands, all it’s doing is accusing the developer of something they didn’t do, causing them to waste valuable development time googling the meaning of the error, finding this thread, and reading about how it isn’t actually their fault, and that they should ignore the issues tab in the future.

This log message is currently expected in development

Oh, it’s expected, is it? And I can’t get rid of it. Okay. I guess that red blob in the corner is now effectively decorational. Why even bother checking it in the future if I know what it says and can do nothing about it?

And thus the value of the tab is entirely lost. And security in electron apps decreases.

What do you propose?

First, if the intention is to warn against something preemptively, the message needs to be reworded as such – with an understandable explanation of the potential problem that has yet to actually happen, but could. Or a link to the relevant MDN page. That works too. As it stands, it’s listing things that haven’t been done (“don’t use eval, new Function(<string>), etc” when the developer has yet to even put any code into the app). Those developers who won’t use eval in the first place (because they listened on day 1 of ECMAScript 101) don’t need to see the error. Those developers who do, won’t see the error anyway if they’ve been conditioned to ignore the issues tab.

Second, the preemptive warning should be information-level until there’s actually a security or eval problem in the program. If that issues tab has been white during development so far, when it suddenly becomes red, we know there’s an issue to fix. If it’s red the whole time anyway, we won’t notice when it becomes a problem, or if the tiny number increments.

Finally, and at the very least, the preemptive warning should be dismissible when there’s no actual security problem. Make it so the developer can put the issues tab back into a neutral state. (And I don’t mean so the error can pop up again next time electron opens, because that makes it effectively not dismissable and prone to being ignored again. I mean like “save a config somewhere per-user per-project” dismissible.) Again, as it stands, all this is doing is teaching people to ignore the issues tab, thus defeating the purported purpose of the message.

I honestly don’t see the value of a preemptive warning in the shape of an error message, so you could just do as the original ticket suggested and make it not appear when there’s not an issue.

I’m also very confused by this. Electron warns when my CSP is insecure but it also warns when it’s very secure. What is the point of this prominent warning?

It’s not safe to use eval. So, if your CSP policy is set to disable eval, it’s for a reason. You can change it.