+- Jellyfin Forum (https://forum.jellyfin.org)
+-- Forum: Support (https://forum.jellyfin.org/f-support)
+--- Forum: Troubleshooting (https://forum.jellyfin.org/f-troubleshooting)
+---- Forum: Networking & Access (https://forum.jellyfin.org/f-networking-access)
+---- Thread: CSP (/t-csp)
CSP - Partition - 2024-04-29
Hey,
I'm struggeling with a proper solution regarding Jellyfin's Content Security Policy.
My current traefik setup follows the general recommendations from the official Traefik v2 guide , but it's missing a good csp header solution for an A+ website certificate.
This topic also has 5 year old feature requests, but I doubt anything is planned at the moment:
- https://features.jellyfin.org/posts/95/implement-a-safe-content-security-policy
- https://features.jellyfin.org/posts/155/csp-compatibility-some-websecurity-standards
My current config looks like this:
Code:
contentsecuritypolicy: " base-uri 'none'; connect-src 'self'; default-src 'none'; font-src 'self'; form-action 'self'; frame-ancestors 'none'; frame-src 'self'; img-src 'self'; media-src 'self' data:; object-src 'none'; script-src 'self'; style-src 'self'"It accomplishes an A+ certificate ( otherwise it's only B ), but I'm unable to resolve the jellyfin subdomain from a browser and the mobile app. The webpage is completely broken, but some apps like the one for Windows and Android TV work.
What should I change in my CSP header config to have a usable webpage untill / if the features get implemented?
RE: CSP - niels - 2024-04-29
This is the CSP I've configured on my own server (via nginx) and it works fine with both Android apps:
content-security-policy: default-src https: data: blob:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' https://www.gstatic.com https://www.youtube.com blob:; worker-src 'self' blob:; connect-src 'self'; object-src 'none'; frame-ancestors 'self'
Do note that this strictly disallows custom CSS/images loaded from other origins.
RE: CSP - Partition - 2024-04-29
(2024-04-29, 07:02 PM)niels Wrote:
content-security-policy: default-src https: data: blob:; style-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline' https://www.gstatic.com https://www.youtube.com blob:; worker-src 'self' blob:; connect-src 'self'; object-src 'none'; frame-ancestors 'self'
Thank you very much for your input. This solution worked for the mobile app and browser, but the csp config is still not safe enough for a valid A+ configuration. The certificate went from B ( no csp config ) to B+.
Here is the output from Mozilla Observatory:
Quote:Test: Content Security Policy
Pass: No
Score: -20
Reason: Content Security Policy (CSP) implemented unsafely. This includes 'unsafe-inline' or data: inside script-src, overly broad sources such as https: inside object-src or script-src, or not restricting the sources for object-srcor script-src.
Furthermore is a broad use of the default-src to "https:" and "data:" not the best option, because a load of other directives fetch the default-src value if you haven't specified them, like child-src, connect-src, frame-src, etc. Regarding the test from https://csp-evaluator.withgoogle.com/?csp=YOURDOMAIN confirmed that the script-src is the most problematic:
Quote:script-src - Host whitelists can frequently be bypassed. Consider using 'strict-dynamic' in combination with CSP nonces or hashes.
'self'
- 'self' can be problematic if you host JSONP, Angular or user uploaded files.
error
'unsafe-inline'
- 'unsafe-inline' allows the execution of unsafe in-page scripts and event handlers.
error
https://www.gstatic.com
- www.gstatic.com is known to host Angular libraries which allow to bypass this CSP.
error
https://www.youtube.com
- www.youtube.com is known to host JSONP endpoints which allow to bypass this CSP.
check
blob:
I removed the 'unsafe-inline', gstatic and youtube links and got an A+ certificate. The trailer won't load in the browser, but that's not a problem for me because the android based apps are using the external youtube app for this. The 'self' definition might also exploitable as a compromised account could upload malicious content over e.x. the profile picture uploader. I try to make my public jellyfin domain as tight as possible to avoid any future exploits, but it seems impossible without the use of 'unsafe-inline' or broader definitions...
There has to be a way to avoid this, but I'm not familiar enough with csp headers (yet).
RE: CSP - niels - 2024-04-30
Those measure tools are just tools. The web frontend for Jellyfin requires inline scripts and data urls so you can't block them in the CSP.
gstatic.com is for chromecast support
youtube.com is for trailers
RE: CSP - Partition - 2024-04-30
(2024-04-30, 05:37 AM)niels Wrote: Those measure tools are just tools. The web frontend for Jellyfin requires inline scripts and data urls so you can't block them in the CSP.
gstatic.com is for chromecast support
youtube.com is for trailers
Thank you for the clarification.
I know that I can't block them in Jellyfins current state, but the goal is to make it as safe as possible without using broad directives that could potentially be abused.
The main.jellyfin.bundle.js is the only file that is referenced in style-src errors while loading without unsafe-inline.
Do you know if this is the only loaded file for the web frontend? Yesterday I was experimenting with the strict-dynamic directive and using hashes for verification, but couldn't get it to work. The strict-dynamic-directive of style-src-attr and style-src-elem in combination of a hash value should allow unsafe-inline, but only from the referenced file with the correct hash.
The only downsite is I have to edit the traefik config when the *.js file gets updated.
Any thoughts about that approach?
Edit: I just noticed you are one of the devs from the android tv app. Great work btw! I came from the Samsung Tizen build and it's a night and day difference to use an official app.
RE: CSP - niels - 2024-04-30
The JavaScript for the frontend is split into multiple files (chunks) and we cannot guarantee the code that needs unsafe-inline is in one specific file for each build.
RE: CSP - Partition - 2024-04-30
(2024-04-30, 08:13 AM)niels Wrote: The JavaScript for the frontend is split into multiple files (chunks) and we cannot guarantee the code that needs unsafe-inline is in one specific file for each build.
Okay I guess I have to check it after each update step by step to see what breaks.
Do you know if there are any plans to reduce the inline scripts for jellyfin to specific files or to make it more transparent what resources are containing them?
For example like the comment from "Shane Lord":
Quote: Ultimately all inline resources need to be moved to their own javascript/style files. See here for easy guidance. This will need to be done by the Jellyfin developers I believe. https://csper.io/docs/guide-removing-inlineThis could potentially help a lot of users who expose jellyfin to the public and are unware of that issue.
BTW if you didn't see my edit: Thanks for your contribution to the Jellyfin project! The AndroidTV app is a night and day difference to the unofficial Samsung Tizen build.
RE: CSP - niels - 2024-04-30
The frontend is slowly modernizing it's stack so inline scripts should disappear over time. Although I can't tell if they would be removed completely in the end.