[Question] Content Security Policy inline style

[douglaswissett]

Hi,

I'm working on a project with Content Security Policy enabled.

When I import this library I get errors like this in the console:
Refused to apply inline style because it violates the following Content Security Policy

1. Does this library support a way to remove inline styles?

2. Is there a recommended approach to extracting inline css styles and moving them to a dedicated css file?

Relaxing CSP to allow inline/unsafe styles isn't an option.

Thanks.

[JorisLimousin]

Same issue for me, and relaxing the CSP isn't an option either. :'(

[cyrildzumts]

This issue is a serious one and it is a shame that it is not addressed. The actual workaround is not an option since it requires changing the CSP rules which is bad. A solution will be to have a css file that could be served by the user.

[crustamet]

With all due respect this CSP inline style is a very important aspect of the security
Please can we get some styles with the default inline style for each tool
We definitely can do this.

And an example demo online version would be really appreciated regarding the CSP headers.

[martijnvankekem]

@neSpecc is there any update to this?

Not supporting CSP is kind-of a deal-breaker for a lot of projects, and editor.js looks absolutely amazing, but isn't up to the standards you'd expect for such a big library in 2023.

I've tried forking and creating a pull-request myself, but the way it is implemented right now, it doesn't seem like a quick-fix of adding a nonce, since the styles are injected into the code at build-time, for each seperate block as well.

[martijnvankekem]

Looks like a good alternative to the style-loader webpack plugin for creating the inline styles.

https://www.npmjs.com/package/extract-text-webpack-plugin

[neSpecc]

Resolved, you can test it in v2.29.0-rc.5

const editor = new EditorJS({
  style: {
    nonce: '2726c7f26c'
  }
})

where 2726c7f26c - cryptographically secure random token generated by your server for each request. This nonce should also be added to the CSP header:

Content-Security-Policy: style-src 'nonce-2726c7f26c'

[martijnvankekem]

Appreciate the quick response @neSpecc!

However, this hasn't been fixed completely. EditorJS depends on codex.tooltips, which doesn't allow for a nonce yet, and this breaks EditorJS as well.

I've created a PR for the codex.tooltips library (codex-team/codex.tooltips#25).
After merging that one, EditorJS should be modified as well to parse the correct nonce into the library.

[martijnvankekem]

Actually,

This only solves a part of the problem. All external tools also apply inline styles, and the nonce isn't there as well. This was what I meant with it doesn't seem like a quick-fix of adding a nonce, since the styles are injected into the code at build-time, for each seperate block as well.

This can be reproduced by the following steps:

1. Add the following to the server object in vite.config.js:

headers: {
      'Content-Security-Policy': 'style-src \'self\' \'nonce-12345678\';',
},

2. Add the nonce '12345678' to all styles loaded in ./index.html.

The following will appear:

[neSpecc]

We can add "nonce" support to the Editor core and its dependencies. And even in all our tools. But you will still need asking about doing same to your 3rd party tools devs.

[G-Rath]

@neSpecc we're very interested in having this situation improved - is there anything we can do to help? I think it's fair to say it's the responsibility of the maintainer to support a nonce be they 1st or 3rd party.

Am I correct in thinking a possible path forward is to convert each plugin to insert their styles in a manner similar to https://github.com/codex-team/codex.tooltips (based on what I see in https://github.com/codex-team/codex.tooltips/pull/25/files), so that they can then support taking a nonce in their config?