security/performance issues with default install

[airflow2010]

After deploying the nextcloud-instance with this script, there are two warnings reported by the instance itself (under admin/settings/administration/overview):

• The "X-Frame-Options" HTTP header is not set to "SAMEORIGIN". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.
• Some columns in the database are missing a conversion to big int.

Both issues can be easily fixed:

For the first issue, add
X-Frame-Options "SAMEORIGIN"
in the "header" section of the Caddyfile.

For the second issue, execute
sudo -u www php /usr/local/www/nextcloud/occ db:convert-filecache-bigint
once after install.

[danb35]

The header is an easy enough fix. I recall putting the database conversion (which leaves aside the question of why a "conversion" is required in the first place, in a brand-new database created directly by Nextcloud--why isn't it created with big int in the first place?) in the script, but taking out because it wouldn't run non-interactively--it required user input to run. Is this no longer the case?

[airflow2010]

This is true, the second command requests user confirmation for the convertion of the database. I don't know if there is a switch to turn it non-interactive. If the database is already in the right format however, the command exits cleanly without interaction. To my mind it would be OK to have the administrator confirm this step, but this is your call.

[Migsi]

This link considers there is a flag to be set for non interactive mode.

[danb35]

Ah, I hadn't seen that earlier. This should be fixed now.

[Migsi]

After deploying the nextcloud-instance with this script, there are two warnings reported by the instance itself (under admin/settings/administration/overview):

* The "X-Frame-Options" HTTP header is not set to "SAMEORIGIN". This is a potential security or privacy risk, as it is recommended to adjust this setting accordingly.

* Some columns in the database are missing a conversion to big int.

Both issues can be easily fixed:

For the first issue, add
X-Frame-Options "SAMEORIGIN"
in the "header" section of the Caddyfile.

For the second issue, execute
sudo -u www php /usr/local/www/nextcloud/occ db:convert-filecache-bigint
once after install.

Regarding the X-Frame-Options, I was unable to fix that by just adjusting the Caddyfile under /usr/local/www/. Is there another Caddyfile which needs to be changed?

EDIT: I just noticed some weird behavior of nextcloud itself. The security check site tells me the missing setting is a security issue, but my browser tells me the header is sent. Can anyone relate to this?

EDIT 2: Nevermind. I just found out that the security check site tests for the setting case sensitive... So the proposed fix was working fine. Anyways, you should correct it to "sameorigin" all lowercase for convenience.

[danb35]

That sounds like the Nextcloud security scanner is being overly picky. Notably, the Nextcloud installation itself doesn't give this complaint:

[Ornias1993]

@danb35 I tested the last 2 versions, both passed both the internal security check AND the Nextcloud Security Scanner.... So this seems solved.

Unless @Migsi Still has this issue, But in that case I doubt it's a code issue in this script to be honest

[Migsi]

@danb35 I tested the last 2 versions, both passed both the internal security check AND the Nextcloud Security Scanner.... So this seems solved.

Unless @Migsi Still has this issue, But in that case I doubt it's a code issue in this script to be honest

As I stated in the EDIT 2 in my last post, the problem was not really related to the script, but to the pickyness of the online nextcloud security scanner, which just didn't like the all uppercase header field. So the problem can be solved by adjusting the script, but IMHO should be fixed by nextcloud, adjusting their scanner to be case insensitive.