duplicated CSP frame-ancestors policy
Describe the bug
On the root path of oCIS, we get two content-security-policy headers. One has a static frame-ancestors 'self' config
Steps to reproduce
- run oCIS 6.3.0 eg. in Kubernetes using the development-install deployment example
- open oCIS, eg https://ocis.kube.owncloud.test/ after opening the network console
- Look at the request to https://ocis.kube.owncloud.test/
Expected behavior
Have one header content-security-policy reflecting my oCIS csp configuration.
Actual behavior
Further context
The second header seems to be statically set to frame-ancestors 'self' and always there, even if I have a more sophisticated CSP config
This additional header probably originates here:
https://github.com/owncloud/ocis/blob/a7a10f8f0c91859b7f3406d39d618ceded9a47e2/services/web/pkg/middleware/silentrefresh.go#L7-L13
And what it actually does: it takes precedence over the frame-ancestors policy in the first header...
@kulmann @JammingBen
Escalating it to P2
As far as I know, the CSP is fully handled by the proxy service (through the csp.yaml file), and no other service should try to set the CSP. The easiest solution is to remove that header from the web service and let the proxy service to handle it; we might need to document that the frame-ancestor 'self' (or a more relaxed) policy is required.
Alternatively, we could implement a way for any service to overwrite the CSP in the proxy service. In this case, the web service would require the proxy service to set, at least, the frame-ancestor 'self' policy. However, the solution seems complex and will require proper design. Note that setting the policy might be critical (service might not work properly if the policy isn't set), and we need to deal with communication errors between the services.
The easiest solution is to remove that header from the web service and let the proxy service to handle it;
Yes. That should do it for now.
https://github.com/owncloud/ocis/pull/10146 should fix the double CSP header.
PR merged. Closing.