CSP - style-src 'unsafe-inline' should not be required
See original GitHub issueExpected Behavior
Chart.js should not depend on the the Content-Security-Policy: style-src 'unsafe-inline'
directive.
Current Behavior
Chart.js adds errors to the console as the css is refused by the CSP rules
Possible Solution
Add a nonce attribute and make it possible to set the nonce. See also: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/script-src#Unsafe_inline_script
Steps to Reproduce (for bugs)
- Add Chart.js to a page
- Open the page with the
Content-Security-Policy: style-src 'self'
directive set
Context
This are the error messages:
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-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU='), or a nonce ('nonce-...') is required to enable inline execution.
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-OTeu7NEHDo6qutIWo0F2TmYrDhsKWCzrUgGoxxHGJ8o='), or a nonce ('nonce-...') is required to enable inline execution.
The first error occurs in platform.dom.js:308 and the 2nd in platform.dom.js:311
Environment
- Chart.js version: 2.7.1
- Browser name and version: Chrome Version 66.0.3334.0
Issue Analytics
- State:
- Created 6 years ago
- Reactions:17
- Comments:15 (4 by maintainers)
Top Results From Across the Web
CSP - style-src 'unsafe-inline' should not be required #1050
Expected behavior react-beautiful-dnd should not depend on the the Content-Security-Policy: style-src 'unsafe-inline' directive.
Read more >CSP: style-src - HTTP - MDN Web Docs - Mozilla
To allow inline styles, 'unsafe-inline' , a nonce-source or a hash-source that matches the inline block can be specified. Content-Security- ...
Read more >unsafe-inline CSP Guide - Content Security Policy
The unsafe-inline Content Security Policy (CSP) keyword allows the execution of inline scripts or styles. Warning. Except for one very specific case, you...
Read more >CSP style-src: 'unsafe-inline' - is it worth it? - Stack Overflow
Personally I find not using unsafe-inline for CSS is impractical. It means I have to use an external style sheet file for EVERY...
Read more >How to prevent the use of unsafe-inline in CSP - Barry van Veen
Hi Geke, you will need to either use hashes or nonces (or not inline the scripts). If this is not possible for you,...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
A nonce is usually a bad solution for most applications. The whole security relies on the hope that it cannot be guessed, since it doesn’t rely on the content it protects. For this to work, the nonce must at least be changed for every request, which requires to dynamically create the HTML and adds further requirements for any user. Otherwise, it is only hiding the underlying issue and creates an (in my opinion) even bigger security problem, as somebody might now trust a still insecure implementation.
A good and secure solution was already pointed out by @panuhorsmalahti, using a hash instead of a nonce and removing the CSS injection.
Going further in this direction, the extracted CSS information could be inserted into a file (lets call it
chartjs.css
) and be delivered together with Chart.js. A simple boolean switch could control whether thecreateDiv
function executesel.style.cssText = style || '';
(so everything remain compatible) or not.The switch could be set via
Lastly, adding some documentation to it, stating how to securely integrate the CSS code:
true
<style src="chartjs/chartjs.css"></style>
as well as deprecating the default injection (so folks know only the secure way would remain after the next major release and could prepare beforehand) could complete this solution and eases the change management pressure.
+1 There is also an issue in: https://github.com/chartjs/Chart.js/blob/3fe198c86098ae50d5d5e9b74d111d5f8fa74bf0/src/platforms/platform.dom.js#L169 which injects data with hardcoded style elements when enabling responsive:true & maintainAspectRatio: false
Since the style injected is static, why not adding CSS classes and adding these class to the targeted element ? This is CSP compliant.