Server: CSP blocks resources

[sebastiansterk]

Steps to reproduce

1. Fresh Install of Nextcloud Docker (nextcloud:17, nextcloud:16, nextcloud:latest)
2. Access the Nextcloud instance
3. Check webconsole in browser

Expected behaviour

Resources should not be blocked by CSP.

Actual behaviour

Resources are blocked by CSP.

Server configuration

Operating system:
Debian 10 Buster (from Nextcloud Docker Image)
Web server:
Apache through Nextcloud Docker Image (nextcloud:17, nextcloud:16, nextcloud:latest)
Database:
mariadb
PHP version:
7.3 (from Nextcloud Docker Image)
Nextcloud version: (see Nextcloud admin page)

Updated from an older Nextcloud/ownCloud or fresh install:
fresh install
Where did you install Nextcloud from:
Official Nextcloud Docker Image (nextcloud:17, nextcloud:16, nextcloud:latest)

Prod Instance:

Local nonprod instance:

Maybe this issue is also related to https://github.com/nextcloud/server/issues/17781
Signing status:

Signing status

Client configuration

Browser:
latest Firefox and latest Chrome
Operating system:
Ubuntu

[kesselb]

Info for anyone who is still seeing requests blocked by CSP in Firefox (even without any extensions) - this appears to be a bug in Firefox.

Details are here https://bugzilla.mozilla.org/show_bug.cgi?id=1591807

https://github.com/nextcloud/server/issues/12724#issuecomment-548361148

Are you able to reproduce the same with chromium browsers?

[osiset]

I am having the same issue. Pages are taking over a minute to load.

Browsers Attempted: Chrome (Desktop and Mobile), Firefox (Desktop and Mobile), Edge (Desktop), Safari (Desktop and Mobile)
Screenshot: Imgur

The NextCloud mobile apps (NextCloud, Bookmarks, Notes, etc) all work fine, WebDav is working fine. Seems to just be an issue with the content policy for browsers.

[osiset]

I wanted to chime in and say I think I solved the issue, turns out it may not be related to browser bug.

• I turned on loglevel => 0 in config.
• Reloaded my page.
• Watched the log via SSH.
• I seen complaints of attempting to compile server.scss but file was locked, being spammed many time.

Solution:

• I had file locking turned on in my config
• I disabled file locking in config
• I disabled memcache in config
• I disabled "theming" app via CLI
• Rebooted the server
• Went to my nextcloud URL
• Success, no errors

Maybe just my case but thats what solved it for me...

EDIT: Reenabled "themeing" app after I had a successful page load. No issues reenabling. Going to attempt to turn back on caching.

[kesselb]

@ohmybrew could you share the exact message for the locked server.scss?

cc @juliushaertl

[osiset]

@kesselb Two messages:

1. Failed to compile and/or save /var/www/nextcloud/core/css/server.scss spammed in
2. Could not find resource css/server.css to load on page load

Disabling the memcache/filelocking solved the issue for the moment, NextCloud was able to rebuild the missing assets (not sure why they disappeared).

I re-enabled it, and all was fine.

I really think the CSP error (for me anyways) came from the fact NextCloud was trying to build those assets, because anything going to /core is directed to PHP/NextCloud, while the page was loading. Due to the locking/memcache it was unable to build the assets, timed out, and caused the CSP error.

[brandonkal]

Can confirm this bug exists in NC 17.0.2
It was introduced in the upgrade from NC 16

[paulcalabro]

I'm seeing this error as well.

[juliushaertl]

Not a nextcloud issue:

Info for anyone who is still seeing requests blocked by CSP in Firefox (even without any extensions) - this appears to be a bug in Firefox.

Details are here bugzilla.mozilla.org/show_bug.cgi?id=1591807

[brandonkal]

@juliushaertl please do not close a valid issue. This is not unique to Firefox. As stated above this is seen in all browsers. This has also been my experience since upgrading to nextcloid 17.

[juliushaertl]

If you can reproduce with Chrome please share the network tab from chrome as well as the console log.

[juliushaertl]

@brandonkal Please also try to provide a more detailed description of which issue you encounter.

[kesselb]

The first report is clearly the firefox issue. Somehow people hijacked the issue with their problem. We don't have a valid issue template except the firefox one so I'm closing this again. Feel free to report a new issue with the initial template so someone can have a proper look.

[aljaxus]

Still getting this error

The screenshot is from v18.0.2

I also just installed a clean install of NextCloud (18.0.2) and the same issue is present.

[kesselb]

Compare curl -I https://cloud.aljaxus.eu with curl -I https://demo2.nextcloud.com and figure out the difference. I would try to disable cloudflare in the first place and check if that might be the issue. Please ask the friendly people at https://help.nextcloud.com/ for advice. GitHub is for bugs not for configuration issues.

[aljaxus]

Compare curl -I https://cloud.aljaxus.eu with curl -I https://demo2.nextcloud.com and figure out the difference. I would try to disable cloudflare in the first place and check if that might be the issue. Please ask the friendly people at https://help.nextcloud.com/ for advice. GitHub is for bugs not for configuration issues.

Fair.

• CloudFlare is not the problem. I also, as mentioned, tested a clean install on another box, on another domain and the same problem was present.
• I will turn to NextCloud forums.

Thank you for such fast reply.

[n3storm]

No cloudflare here and same error.

[foorschtbar]

Same problem here. Fresh installed Nextcloud...

[SupRavII]

Same problem, Nextcloud 18

[sebastiansterk]

@kesselb as you can see many people are facing this issue. Could you please check if it makes sense to reopen this issue? Thanks

[kesselb]

What issue are you facing exactly? Is there something broken or just the blocked resources in networks?

juliushaertl posted a link to mozilla's bug tracker about 5 months ago. That issue is open.

If you see those blocked csp requests in Firefox but not with Chrome (or any other chromium based browser) and your instance works fine there is nothing to worry.

[burner-account]

Just some feedback on this topic. We had a busy nextcloud instance in a small "non-chrome" org (<250). Well, now we have another file store and lost the nice stuff integrated into nextcloud. All directly caused by the no-chrome rule.

So if there had been a work-around that could have kept us using nextcloud, we would have been happy campers.

What i am trying to say: It is not your responsibility, but you lost users anyway.

[kesselb]

What issue are you facing exactly? I'm not aware of any functional issue.

[felix]

Same problem, Nextcloud 18

I experience exactly this in FF 76 and Chromium 83 on macOS. I don't believe it is a FF issue.

[kesselb]

To triage this issue we need:

• Issue template for your instance with all information.
• Compare the header (curl -I) from your instance with a demo instance (request one at try.nextcloud.com)
• If possible the url to the instance.
• Beside the blocked request what does not work? Can you login and upload files?

[aljaxus]

@kesselb The same issue is present on the demo Nextcloud instance (via try.nextcloud.com) ;

---

Some info:

• on Windows 10, Version 10.0.18362 Build 18362
• Firefox 75.0 (64-bit)
• Firefox "Enhanced tracking protection" - tested with enabled and disabled, both result in same scenario

[kesselb]

@aljaxus you see the same issue with Chrome on the demo instance?

[aljaxus]

@aljaxus you see the same issue with Chrome on the demo instance?

I do not. Using chrome Version 81.0.4044.129 (Official Build) (64-bit)

[kesselb]

If you see those blocked csp requests in Firefox but not with Chrome (or any other chromium based browser) and your instance works fine there is nothing to worry.

That's the Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1591807

If someone has the blocked csp resources with Firefox AND Chrome please post:

• Issue template for your instance with all information.
• Compare the header (curl -I) from your instance with a demo instance (request one at try.nextcloud.com)
• If possible the url to the instance.
• Beside the blocked request what does not work? Can you login and upload files?

I'm still having issue to understand your problem. I see those blocked csp resources as well but my instance works fine. It's possible to login, upload files, create users, etc.

@burner-account @felix @SupRavII beside the blocked request was there something else not working?

[sebastiansterk]

I'm still having issue to understand your problem. I see those blocked csp resources as well but my instance works fine. It's possible to login, upload files, create users, etc.

Because you have the blocked resourced already in your local browser cache. If the resources are getting blocked and you do not have these blocked resources in your local browser cache then nothing works anymore.

[kesselb]

[burner-account]

@kesselb Please excuse my late answer. I don't recall any other issue. But since the blocking behaviour prevented users/admins from logging into nextcloud, nothing could have triggered other errors on our end.

[mritzmann]

Find this an interesting issue/thread.

Most of the comments refer to Mozilla Firefox. There, as already noted by others, is a known Firefox bug. But the bug is not so tragic, because the resources are loaded on a second request. Also, the bug must be fixed by Mozilla and not Nextcloud. So the Firefox problem is not really a problem at this time.

---

The following users report that the problem also happens in Chrome:

Chrome (Desktop and Mobile), Firefox (Desktop and Mobile), Edge (Desktop), Safari (Desktop and Mobile) -- @osiset

But the user could already solve the problem, apparently a caching problem. There was a problem with memcache, not necessarily a nextcloud problem. This can have many reasons.

---

Other users also mention problems with Firefox, but then don't answer once you point out that it is a known Firefox problem. Any many don't write if they have only seen the error messages or if there are actually problems.

And theres User like @burner-account:

What i am trying to say: It is not your responsibility, but you lost users anyway.

I mean: Seriously?! The issue is open since 2019 and only a few users have problems. And most of them have only seen the error message, but the installation works anyway -- because it's in there case the Firefox bug. Nextcloud is used by hundreds of thousands of users. It is very unlikely that many users have problems and say nothing.

The problem that no login is possible, or parts are missing in the admin interface, cannot be reproduced by any Nextcloud developer. Otherwise someone would obviously have started looking for the problem long ago. In IT you have to admit that sometimes the problem is not in the software you use. Maybe a manually caused configuration error. Or a faulty app. Or a faulty LAMP/LEMP-Stack. Or a server side caching problem. Not everything is always a problem of the software you use. The difficult thing about such problems: These are all problems that nobody can solve here because they are not reproducible. Debug yourself! Get involved! Answering here only with meaningless screenshots and sentences without technical details does not help at all.

[sebastiansterk]

It's just Nextcloud (local instance, public instance, demo instance) on my Chrome & Firefox that is causing this issue, never had this issue for other applications/websites. According to your statement, let's close this issue....

[rasos]

We had the same rendering issue with Firefox and Chrome browsers, all js files were CSP blocked. We could track it down to a Redis issue.

How to fix it:

• make a backup of your config.php file
• remove all Redis settings
• open your instance in browser - all pages should load without Redis cached css and js files
• put back your pevious config.php file

UPDATE: The CSP behaviour came back after one day of operation with Redis. Deactivated Redis now completely, pages render okay now.

[Cybolic]

While this is a Firefox issue, I think it's worth mentioning that it causes Firefox to wait for 25 (on my instance) requests to be blocked before trying them again on every page load; this causes a wait of up to several seconds per page, making Nextcloud seem much slower than it actually is.
As @sebastiansterk also mentions, I've never seen this issue elsewhere, so even though it's not technically a Nextcloud issue, the user experience makes it seem like it is.

[kesselb]

I don't get it. I asked for more information more than once. Every Nextcloud setup is different. To have a starting point for further debugging we need at least the issue template (and the other information I requested in the meantime). Also check if you see the same issue with: https://try.nextcloud.com/.

requests to be blocked before trying them again on every page load; this causes a wait of up to several seconds per page,

That's bad but how does your post pushes this issue forward? You missed that we still waiting for more information and closed the issue because noone ever provided it? I could imagine that some app is responsible for such blocks as well.

I've never seen this issue elsewhere,

https://www.troyhunt.com/locking-down-your-website-scripts-with-csp-hashes-nonces-and-report-uri/

[sebastiansterk]

@kesselb in my first post, I mentioned that this is reproducible in the Nextcloud docker image. Fresh installation w/o additional configuration. Please let me know what is missing

[kesselb]

@sebastiansterk https://github.com/nextcloud/server/issues/17783#issuecomment-623966176

[kesselb]

let me know what is missing

To be more precise: I'm still looking for a way how to reproduce that issue. What issue exactly? A situation when scripts are not loaded in Chrome and Firefox caused by a broken / invalid / missing / whatever csp configuration / header.

reproducible in the Nextcloud docker image

Just started a fresh container (nextcloud:18-apache) on a random port and run the setup. Visited the page with Chrome and Firefox (cache disabled via dev tools). I see the blocked request in Firefox. I don't see blocked request in Chrome. It's possible to login, upload files, etc.

[Cybolic]

@kesselb
From my point of view, the issue is not that functionality is broken, but that requests take much longer than they should. That can then be a wont-fix, but it would be nice to find a way to not end up that much slower than other provider options, especially when companies trying out Nextcloud might not know that Firefox is the culprit or might not be able to easily switch from Firefox.

Considering that you saw the issue yourself, I'd think the issue as reported (not broken functionality) should be considered confirmed by now.

I could imagine that some app is responsible for such blocks as well.
This occurs on a fresh install, like you mentioned as well.

[kesselb]

I'd think the issue as reported (not broken functionality) should be considered confirmed by now.

I'm only interested in setups with broken functionality (e.g it's not possible to login).

but that requests take much longer than they should.

I'm not able to confirm this observation. The difference in time until the page is delivered between Firefox and Chrome is minimal. If you run into the situation with a notable different (keep in mind most people don't disable the cache) the issue must be something different. That's actually my biggest concern about this Firefox issue. People assume that their problem is somehow related to this blocked request but the issue is something different. If you have proof that the requests take much longer because of the blocked request feel free to add it.

[Cybolic]

If you have proof that the requests take much longer because of the blocked request feel free to add it.

Other than usage seems about twice as fast in Chrome or Brave than in Firefox and that Firefox's inspector shows the second request being stuck waiting for the requests that cancel, I'm not sure what to add.
The README mentions using BrowserStack for testing, maybe something can be set up there? I'd check, but I couldn't find anything regarding it in the repo.

[SupRavII]

If you see those blocked csp requests in Firefox but not with Chrome (or any other chromium based browser) and your instance works fine there is nothing to worry.

That's the Firefox issue: https://bugzilla.mozilla.org/show_bug.cgi?id=1591807

If someone has the blocked csp resources with Firefox AND Chrome please post:

* Issue template for your instance with all information.

* Compare the header (curl -I) from your instance with a demo instance (request one at try.nextcloud.com)

* If possible the url to the instance.

* Beside the blocked request what does not work? Can you login and upload files?

I'm still having issue to understand your problem. I see those blocked csp resources as well but my instance works fine. It's possible to login, upload files, create users, etc.

@burner-account @felix @SupRavII beside the blocked request was there something else not working?

@ burner account @felix @SupRavII next to the blocked request, was something else not working?

Hello kesselb

among the problems encountered with this CSP blocking I will list mine.

For information I have two instances of NEXTCLOUD on two different servers: NEXTCLOUD 18 permanently updated including for Plugins.

Firefox or Chrome or Chomium (Linux)

• obligation to validate 3 times LOGIN / PASSWORD to enter (user or admin)
• obligation to validate 3 times LOGIN / PASSWORD to use:
  (calendar / contacts / email and configuration parameters)
• Cannot create a directory or upload with Firefox or Chrome or Chomium (Linux)
  this works very well with the Linux Client or the Android Client (NextCloud Client OK / sync OK / upload OK) with the same login and the same password

Here are the main problems encountered and still topical for me.

[SupRavII]

Perfect descriptor of the major problem encoutered
3 times enter LOGIN / PASSWORD to enter (user or admin)

[kesselb]

Perfect descriptor of the major problem encoutered

No. I don't have a login at this instance (it's the instance of sebastiansterk who started this topic). I shared this screen cast to demonstrate that (although some scripts are blocked) it's possible to submit a login request and switch to the reset password form.

For information I have two instances of NEXTCLOUD on two different servers: NEXTCLOUD 18 permanently updated including for Plugins.

If someone has the blocked csp resources with Firefox AND Chrome please post:

• Issue template for your instance with all information.
• Compare the header (curl -I) from your instance with a demo instance (request one at try.nextcloud.com)
• If possible the url to the instance.
• ~Beside the blocked request what does not work? Can you login and upload files?~

[illuusio]

I tested with my instance (behind couple of proxys) and try.nextcloud.com and get same CSP errors as I get from my own instance.

These are my headers (curl -I)

server: nginx/1.16.1
date: Tue, 16 Jun 2020 11:31:09 GMT
content-type: text/html; charset=UTF-8
location: https://alice.in.wonderland/login
set-cookie: oc9wfwesjsa5=c787d0e1ba451f3b19cf04abf45ab4f1; path=/; secure; HttpOnly
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
pragma: no-cache
set-cookie: oc_sessionPassphrase=MIRMaCBXUbhCkGVoc5XIqB9vUBoh%2BZK9u72uBStUMYPKfuaXgO5%2BA4%2F0QfQfBtsWaBWNUijJsnJRQoLWyIhjc2SibvTI4V4ythokI05ZdtYP6djwmfx3S99KRMmk9I2z; path=/; secure; HttpOnly
content-security-policy: default-src 'self'; script-src 'self' 'nonce-QXQxTkZ5TVNNVVRYVjNZc2NubGlxYytuNFpGTEIwKzhIcWZWYmEzeEVrcz06V3BVYWYxRlJlZzZZSjExbU95QXUwTHJ3bGVZb1VUM1JUUEM4Rzg2NFl5ND0='; style-src 'self' 'unsafe-inline'; frame-src *; img-src * data: blob:; font-src 'self' data:; media-src *; connect-src *; object-src 'none'; base-uri 'self';
set-cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
set-cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
strict-transport-security: max-age=63072000
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
x-xss-protection: 1; mode=block
strict-transport-security: max-age=63072000
x-frame-options: SAMEORIGIN
x-content-type-options: nosniff
x-xss-protection: 1; mode=bloc

and these are try.nextcloud.com

Date: Tue, 16 Jun 2020 11:30:47 GMT
Server: Apache/2.4.29 (Ubuntu)
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Pragma: no-cache
Referrer-Policy: no-referrer
X-Content-Type-Options: nosniff
X-Download-Options: noopen
X-Frame-Options: SAMEORIGIN
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: none
X-XSS-Protection: 1; mode=block
Cache-Control: no-cache, no-store, must-revalidate
Content-Security-Policy: default-src 'none';base-uri 'none';manifest-src 'self'
Feature-Policy: autoplay 'none';camera 'none';fullscreen 'none';geolocation 'none';microphone 'none';payment 'none'
Set-Cookie: ochf57vslr2g=2pdba20ll6ikefiqo1r07iloaj; path=/; secure; HttpOnly
Set-Cookie: oc_sessionPassphrase=AkpwQ%2FFRwq1QNkkf7S%2F4l63JUUQ2sfkw6r3wBKMxxn8cmBAQKAWdYqnma0ufQCse6fvum1NtZC13irQJxTN%2BT9C5qaeLXvHhlVLUVZXJ622XaVwx4wnvHLbTmGlm2C%2BS; path=/; secure; HttpOnly
Set-Cookie: __Host-nc_sameSiteCookielax=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=lax
Set-Cookie: __Host-nc_sameSiteCookiestrict=true; path=/; httponly;secure; expires=Fri, 31-Dec-2100 23:59:59 GMT; SameSite=strict
Content-Length: 43
Content-Type: application/json; charset=utf-8

I think these are headers that are diffrent (I use NGINX and otherwise try.nextcloud.com is on Apache2 httpd

My
expires: Thu, 19 Nov 1981 08:52:00 GMT
cache-control: no-store, no-cache, must-revalidate
x-xss-protection: 1; mode=block
strict-transport-security: max-age=63072000
x-content-type-options: nosniff

try.nextcloud.com
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Referrer-Policy: no-referrer
X-Download-Options: noopen
X-Permitted-Cross-Domain-Policies: none
X-Robots-Tag: none
Feature-Policy: autoplay 'none';camera 'none';fullscreen 'none';geolocation 'none';microphone 'none';payment 'none'
Content-Length: 43

There is small amount of headers. I can log in/upload and download so this kind of small problem to me.

[Exagone313]

I got a similar (?) issue with Nextcloud 18.0.6 on Firefox 78 and Chromium 83. I temporarily changed CSP header to do not use a nonce (affected by it too), but I still get some scripts that randomly fail to load in both web browsers on login page. Sometimes, refreshing and login form is back, sometimes not.

On Chromium I saw that loading of scripts may fail with ERR_INCOMPLETE_CHUNKED_ENCODING (Firefox just says that loading of some scripts failed without anything to debug). This is probably an issue from my reverse proxy config. I won't open an issue since it doesn't appear to be related to Nextcloud itself, but I felt right to post this comment here in case another user gets here too.

[illuusio]

I think this is somehow problem about double CSP headers which confuses Mozilla SSL tester too

[mashedkeyboard]

Clean install of the latest version of Nextcloud, using both snap and setup-nextcloud.php installs, results in this issue. It's not a browser issue; I can replicate it in both Chrome and Firefox. What's more, it's self-evidently not a browser issue, because there _literally aren't any nonce attributes being set on <script> elements_.

For example, one of the scripts my Nextcloud instance is serving is <script nonce="" defer="" src="/core/js/dist/main.js?v=def2ba59-0"></script>. Clearly, that's not going to work with nonce-based CSP authentication, because there's no nonce to authenticate against!

Any ideas why this might be happening? I definitely think the issue needs to be re-opened.

Edit: Hrm, that's... really weird. It looks like it actually _is_ being served - using cURL to request the page is working - but something is happening to it to get rid of it before it's actually used. And it's not a browser extension, because my Chromium install is extension-free... Something very odd is going on here.

[narcisgarcia]

Using Nextcloud 20.0.0 with Iridium/Chromium
Collabora Online (version 4.2.8) does not load unless I disable whole Content-Security-Policy at Apache virtualhost.

Header set Content-Security-Policy "default-src 'none'; img-src 'self' data:; media-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline' data:; font-src 'self' data:; object-src 'self'; base-uri 'self'; connect-src 'self'; form-action 'self'; frame-ancestors 'self'"

Can I tune Content-Security-Policy someway to be fully usable with Nextcloud 20 ?