Content-Security-Policy blocking inline styles

[patrickschaper]

Describe the bug
CSP is used to prevent loading of unknown (external) content.

When using the CSP header (MDN - Content-Security-Policy) errors regarding inline styles are thrown.

Errors from Chrome

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' *". Either the 'unsafe-inline' keyword, a hash ('sha256-G9HE193eO6y+LplDmtl+aVc/LpxxoFx1mvFRYe8lL4Q='), or a nonce ('nonce-...') is required to enable inline execution.

leading to head.insertBefore(styleEl, head.firstChild); which inserts a style node.

Refused to apply inline style because it violates the following Content Security Policy directive: "style-src 'self' 'nonce-rEyAt_9xnN_KsoGrrXp_SQ=='". Either the 'unsafe-inline' keyword, a hash ('sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='), or a nonce ('nonce-...') is required to enable inline execution.
_completeHide @ vendor.26c5e80486acd09eba6a.js:31 [...]

which leads to this.el.setAttribute("style","")

To Reproduce

• Go to the CodePen example https://cdpn.io/imgix/fullpage/WrRmLb
• Use extension to modify response headers and add "Content-Security-Policy" with value "style-src *"

Best way is to use incognito mode so other extensions don't interfere (but allow header modifying extension)

Steps to reproduce the behaviour:

1. Load page (triggers load time error)
2. moving out of image (triggers style removal error)

Expected behaviour
Drift code not being blocked.

Information:

• drift version: v1.4.1
• browser version: Firefox 65, Chrome 88 (presumably see introduction of CSP in browsers https://caniuse.com/contentsecuritypolicy2)

[sherwinski]

Hey @yesman82, thanks for opening this issue. We'll look into this and reply back sometime in the next few days 👍

[sherwinski]

Hey @yesman82, you should find the fix for this issue in v1.4.2 🎉

[luqven]

Hey @yesman82 , we’ve looked into this Content Security Policy (CSP) issue some more and wanted to give an update.
We initially hoped that by directly modifying attributes instead of using setAttribute() we could sidestep CSPs that blocked our scripts. After some trial and error, it became evident that, by design, CSPs are difficult and at times nearly impossible to bypass if they are especially strict or incorrectly defined.

For example the "style-src 'self' *" CSP makes drift script execution impossible. Technically, the CSP would need to include a hash or unsafe-inline to allow for inline executions, which are the type of executions drift preforms to insert its stylesheets in the document head. Despite the fact the CSP directive lists self , or the current origin, as the style-src, without unsafe-inline or a hash of the styles being applied also included as directives, the inline scripts that modify the page’s styling will not be allowed to execute by the browser.

The second CSP cited in the issue, "style-src 'self' 'nonce-rEyAt_9xnN_KsoGrrXp_SQ=='" , attempts to make use of a nonce. This could work with drift so long as the server assigns a nonce to drift tags. In this case, one of the style tags in question, the one being generated inline through a script, does not have that, or any, nonce assigned. The CSP will therefore block it. In order for drift to work with this CSP it would need to include unsafe-inline , a hash of the styles being applied by drift, or include more nonce declarations that encompass all the styles being applying inline (which since they’re being generated by drift scripts would not be easily done).

Therefore, to address CSP issues you mentioned above, or any that might come up as a result of using drift, it’s recommended you take a look at the updated index.html in the project’s root directory. There, you’ll see an example of a CSP that specifically includes drift style tag hashes. When opened in the browser, you’ll note the page does not generate any CSP violations or errors related to any drift code execution.

Please note that while it is possible for users to ‘allowlist’ drift by including <scheme-source> information in the CSP (ie data, filesystem, etc), that’s not recommended due to the insecurities those options introduce. This is why we opted for hashes in our CSP.

Thank you again for bringing this issue to our attention and please feel free to open this again if there’s anything we might have missed.