Blocked by CSP Header

[Codehardt]

Hi,

When I set the Content-Security-Policy Header to default-src 'self';, the Lines aren't rendered correctly anymore, because some Inline-Styles are blocked by the CSP.

I guess that the issue is caused by the <style>...</style> in the leader-line-defs.

The solution would be to either set all stylings with JavaScript or move the stylings into a separate CSS file.

Setting the CSP to unsafe-inline is no option for me.

[Codehardt]

I temporary fixed this issue for me, by forking your project to github.com/Codehardt/leader-line. I then patched the Gruntfile.js to create a separate leader-line.min.css file instead.

The newly bundled version has been published on npm www.npmjs.com/package/@codehardt/leader-line.

I am now able to use your package by importing it as follows:

import LeaderLine from "@codehardt/leader-line"
import "@codehardt/leader-line/leader-line.min.css"

FYI: I am using your package in a React project so I also had to add

if(module&&module.exports){module.exports=LeaderLine;}

to the leader-line.min.js before publishing it on npm.

Kind regards, Marcel

[anseki]

Hi @Codehardt, thank you for the information and custom version. A practical way for many libraries I think is specifying style-src. Anyway, thank you for your time. :smile:

[Codehardt]

Hey @anseki, thanks for your fast reply.

The problem with style-src is as follows.

There are currently 3 ways to configure style-src:

1. using unsafe-inline: This is not recommended as it allows an attacker to change the style of your whole page. There is no way to just unsafe-inline for svg.
2. using nonce: To set a nonce for the <style>...</style/> the server has to randomly generate a nonce and put it in the <style> tag. This package does not support changing the nonce attribute of the <style> tag so this is no applicable.
3. using SHA256 hash: This is still experimental and not supported by all browsers

Or did I miss something?

[anseki]

Yes, you seem to have missed the purpose for using the library and the CSP maybe. There is a trade-off between flexibility and security. Then, a few mechanisms such as style-src are provided for cases that absolutely have to use something that is blocked by CSP. Therefore, if you think that those workarounds have a problem, you should not use those and the library. You can draw lines without the library if you know SVG because the LeaderLine is a simple library to generate a SVG image conveniently, and that drawing is easy for almost cases. That is, the library is not required for you. In other words, you should not use those libraries that don't conform your security policy.

[Codehardt]

Then, a few mechanisms such as style-src are provided for cases that absolutely have to use something that is blocked by CSP.

As I already mentioned, the above workaround with the patched Gruntfile.js and a manual import of the automatically generated leader-line.min.css is working for the most strict CSP header. The CSP header isn't made to block any dynamically set stylings. It is made to just disable stylings set with <style>... or with e.g. <div style="...">. Changing the style with

var el = document.getElementById(...)
el.style.<cssprop> = <cssval>

is still fine for CSP because this is done by static JavaScript files.

The only problem with your package (that is by the way still very awesome and useful) is the CSS part in the <[DATA section.

Most JavaScript packages that contain JS mixed with some stylings provide any way to fix the CSP issue and it doesn't require a complete refactor.

Take Fontawesome as an example, a toolkit to draw hundreds of different icons in your HTML page with JS and dynamically generated SVG, similar to your package. When I embedded that package, I also got issues with the CSP, but Fontawesome has a simple workaround that you could implement, too:

To use Fontawesome with CSP, you can tell Fontawesome to not embed CSS unsafely, by setting the option Fontawesome.config.autoAddCss = false, similar to your LeaderLine.positionByWindowResize option. The css then has to be imported manually with <link rel="stylesheet" href="<path>/<to>/fontawesome.min.css"> Let's imagine you implement a LeaderLine.autoAddCss = false option. Nothing would change for users that use your package. But for those who require a strict CSP header, they can then change LeaderLine.autoAddCss to false and import your leader-line.min.css manually.

See fontawesome.com/docs/web/dig-deeper/security for more information.

You can draw lines without the library if you know SVG because the LeaderLine is a simple library to generate a SVG image conveniently, and that drawing is easy for almost cases. That is, the library is not required for you. In other words, you should not use those libraries that don't conform your security policy.

Your package is so awesome and saves so much work that I don't want to implement manually. I do not build a static webpage that renders svg arrows that do not change anymore. I render a complex network graph with your package that connects lot of different nodes that can be added and removed manually, some have to be animated, some should be rendered yellow due to a "broken network connection". Of cause this could be done by simply generating svg for myself but this would take me at least as long as it takes you to implement this package. So I don't wanna miss your package.

But if you don't want to patch this CSP issue, I'm totally fine with it. Then I will stay on my fork and regularly check for updates on your package. But your package is used by a lot of users and I don't understand why I am the first one who requires that strict CSP? So feel free to close this issue if you are fine with that.

[anseki]

Sorry, my English is poor. Your words are difficult for me. However, that might help something. Then you will understand CSP. Thank you for the information. :smile:

[anseki]

This unrequired issue is closed.