CSP

[Partition]


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:

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:

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).