text layer style micro-optimization resulted in requiring style-src 'unsafe-inline' in Content Security Policy
See original GitHub issuehttps://github.com/mozilla/pdf.js/commit/cb5f9df0c8932fe0db9f783ede7893b7efcadcdb started generating style strings automatically, which is forbidden by a standard Content Security Policy. It would be nice to have a fallback or perhaps reconsider the approach.
To reproduce, use style-src 'self'
in CSP:
<meta http-equiv="Content-Security-Policy" content="style-src 'self'" />
Issue Analytics
- State:
- Created 7 years ago
- Reactions:6
- Comments:11 (2 by maintainers)
Top Results From Across the Web
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 >CSP Allow Inline Styles - Content Security Policy
Create a CSP Policy that allows execution of inline styles. ... policy: the page's settings blocked the loading of a resource at inline...
Read more >Safari Technology Preview Release Notes - Apple Developer
Fixed inline box decoration position when the content box is vertically shifted with text-underline-position: under in a vertical writing mode (254554@main, ...
Read more >Use Tag Manager with a Content Security Policy
To use Google Tag Manager on a page with a CSP, the CSP must allow for the execution of your Tag Manager container...
Read more >Content Security Policy - OWASP Cheat Sheet Series
By injecting the Content-Security-Policy (CSP) headers from the server, the browser is ... style-src-elem controls styles except for inline attributes.
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
In case anyone else comes across this and wants a solution, this is my current patch rolling this back to the old way of doing it so
style-src: 'unsafe-inline'
can be avoided:https://github.com/GrapheneOS/pdf.js/commit/021d2fddb03883054ef4399d1d3df87e0c6ab9ca
It can definitely be optimized a bit, but since that doesn’t matter for my usage I’m keeping the patch as minimal as possible for ease of maintenance. I think expecting someone that wants this security issue fixed to care about optimizing the performance is a bit backwards. The performance optimization should have been constrained to what can be done without breaking basic security hygiene. It may even be faster to approach this in a different way as I mentioned above. The commit message for the optimization mentions how difficult it was to even measure a difference, but the security regression is quite easily measured.
The reason that I’m using pdf.js in the first place is security. It allows reusing the hardened / sandboxed browser rendering with all the PDF-specific rendering in a memory safe language (JavaScript). As part of doing this, I’m using CSP to mitigate dynamic code / style injection which could massively increase the attack surface to being like a web page, which is very counter to the goals. I think many other people have a similar use case for pdf.js for avoiding dangerous native PDF rendering libraries. Avoiding
unsafe-inline
styles is part of making sure that a bug cannot result in accidentally injecting arbitrary styles, opening up a lot of renderer attack surface. For a use case where it’s embedded in an actual web site, it matters even more, since lots of evil things can be done with CSS.I consider this on the same level as expecting native binaries / libraries to have SSP, ASLR (PIE),
_FORTIFY_SOURCE=2
, -fstack-clash-protection and other baseline mitigations. It’s basic security hygiene vs. more advanced things like type-based CFI, trapping integer sanitizers, ShadowCallStack, etc. where I do expect larger projects to be thinking about it and perhaps already working on it but it’s not part of the bare minimum. A basic CSP policy with static JavaScript / CSS qualifies as basic security hygiene in my opinion.Fixed by the pull request above.