Site embedding (X-Frame-Options) partially broken since Cloudron 4.1.3

[subven]

Since 4.1.3 I have a hard time embedding sites to Nextcloud when using the "External Sites" plugin.

My domain is domain.com and the embedded site is sub.domain.com. For example it's working for Rocket.Chat but fails for Roundcube or Etherpad.

# Chromium 74
Refused to display 'sub.domain.com' in a frame because it set 'X-Frame-Options' to 'sameorigin'.

# Firefox 67
Load denied by X-Frame-Options: sub.domain.com does not permit cross-origin framing.

curl -v domain.com says < x-frame-options: SAMEORIGIN but I can't find this entry in any of the nginx config files. Does it come from PHP directly?

I tried to set proxy_hide_header X-Frame-Options; without success. Then I went full crazy mode and added add_header Content-Security-Policy 'frame-src https://sub.domain.com'; but it gets overwritten by the X-Frame-Options

Nextcloud 16 Documentation --> Linking external sites

[girish]

@subven said in Site embedding (X-Frame-Options) partially broken since Cloudron 4.1.3:

curl -v domain.com says < x-frame-options: SAMEORIGIN but I can't find this entry in any of the nginx config files. Does it come from PHP directly?

Indeed, this is the mystery. The Cloudron nginx config does not set these variables anymore (since they are obsolete) ie. we removed this in Cloudron 4.1.3. I am pretty sure it doesn't come from the app either. This can only mean that maybe the nginx on Cloudron is not "reloaded" with the latest configuration. Can you try systemctl reload nginx or systemctl restart nginx on Cloudron? Does curl then respond without the X-Frame-Options?

[girish]

FWIW, you can also restart nginx from System -> Services.

[subven]

@girish the nginx configuration is fine and I have reloaded it correctly each time. I guess it's the app, maybe the apache2 inside the container. I'll dig a little deeper.

Is someone able to reproduce my problem?

Edit: It's not the apache2.

root@9cff92f2-cf59-4a7e-9455-5261ee1fe533:/etc/apache2/conf-enabled# cat security.conf | grep sameorigin
#Header set X-Frame-Options: "sameorigin"

OK I figured it out. It's the Roundcube app itself and it's a little bit sketchy. I do some research and update this post.
Because I initially wrote that it's happening for roundcube AND etherpad...the mistake was on my side. I embedded etherpad from another domain what clearly could not work in this case. So it was just roundcube from the beginning.

So the (temporary) fix for me is to add proxy_hide_header X-Frame-Options; to the roundcube app nginx config.

root@v22019044939886250:/etc/nginx/applications# cat 211a9c92-26e4-456a-a28e-e6c550bf611b.conf | grep proxy
    proxy_hide_header X-XSS-Protection;
    proxy_hide_header X-Download-Options;
    proxy_hide_header X-Content-Type-Options;
    proxy_hide_header X-Permitted-Cross-Domain-Policies;
    proxy_hide_header Referrer-Policy;
    proxy_http_version 1.1;
    proxy_intercept_errors on;
    proxy_read_timeout       3500;
    proxy_connect_timeout    3250;
    proxy_set_header   Host               $host;
    proxy_set_header   X-Forwarded-For    $remote_addr;
    proxy_set_header   X-Forwarded-Host   $host;
    proxy_set_header   X-Forwarded-Port   $server_port;
    proxy_set_header   X-Forwarded-Proto  https;
    proxy_set_header   X-Forwarded-Ssl    on;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_hide_header X-Frame-Options;
    # only serve up the status page if we get proxy gateway errors
        # increase the proxy buffer sizes to not run into buffer issues (http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_buffers)
        proxy_buffer_size       128k;
        proxy_buffers           4 256k;
        proxy_busy_buffers_size 256k;
        proxy_max_temp_file_size 0;
        proxy_pass http://127.0.0.1:46363;

[girish]

@subven For roundcube, you can set $config['x_frame_options'] = false; as per https://github.com/roundcube/roundcubemail/blob/f6807bcc4c60def86e82a6c36914f0d55af04a33/config/defaults.inc.php#L509

For cloudron, you can set it in /app/data/customconfig.php

[subven]

Changed As it is the default configuration for Roundcube it is working like intended and we could leave it like this? I don't think its a rare use case but maybe it could be added to the documentation (which I always found very helpful).