Edit Content Security Policy

Description

I would like to edit the Content Security Policy as the default one may not be compliant and I would like to ask is it possible to have a custom Content Security Policy?

Understand that we can turn off the ‘Enable Content Security policy’ but it does not help us in the situation as it will remove the CSP completely. The function of Extra CSP Domains will only add to the default Content-Security-Policy.

Steps to reproduce:

    1. Make any valid request to a self-hosted rocketchat:
  • e.g. curl -v -k https://“rocketchat domain”
    1. Observe the response headers to see the following:
    • The deprecated “X-XSS-Protection” header is in use.
    • The “Content-Security-Policy” uses unsafe values such as “unsafe-eval”.
    • The “Content-Security-Policy” is missing the “object-src” directive.
    • The deprecated “Pragma” header is in use.

Configuration that we would like to set:

  • Remove the deprecated X-XSS-Protection headers.
  • Remove the unsafe values from the script-src directive in the Content-Security-Policy such as unsafe-eval
  • Set an appropriate value for the object-src directive in the Content-Security-Policy such as none
  • Remove the deprecated Pragma header if it is not required

Server Setup Information

  • Version of Rocket.Chat Server: v6.9.2
  • Operating System: Linux
  • Deployment Method: docker
  • Number of Running Instances: 1 server and 1 database instance
  • NodeJS Version: 14.21.3
  • MongoDB Version: 6.0.15

Ah - so you opened these issues?

Please stay in one place as it gets confusing to manage. I suggest stay in the issues.

I have requested some attention on both the issues but I have no idea on the outcome.

If they are considered a security issue they will of course be dealt with.

If they are essentially a feature request then there is no guarantee of the outcome. PRs are of course welcome.

See what the devs say.

NB - I think you are trying to test against say 127.0.0.1:3000

Rocket does not recommend anyone runs Rocket.Chat via http or directly. It should always behind a reverse proxy.

Hi,

Thank You for the swift response by the team!

Understand on staying in one place as I was unsure which forum would be better suited to my queries.

In any case, is it correct to say that there is no way to edit the default CSP, provided that I set up an nginx reverse proxy at the front and configure my own proxy header for the CSP?

Appreciate your help and thank you!

The short answer to fix the issue is to front with a proxy.

This is well documented.

https://docs.rocket.chat/docs/configuring-ssl-reverse-proxy

Personally I use apache for historical reasons, but same thing and I do not see your issue on my servers unless I connect directly locally and bypassing the proxy.

As far as your issue is concerned it is being looked at, but no idea on outcome. It will pass through the usual backend processes.

Follow on github.

Hi,

Noted on the recommendations. I will configure it on my end.

Thank you for the clarification!

Hi Team,

I was successfully able to remove the deprecated X-XSS-Protection and the add the “object-src” directive as per my question from above via installing apache at infront of the application.

However I ran into an issue while trying to remove unsafe-eval from the Content-Security-Policy.

The error message I discovered after inspecting the page when it is loading is as below:

"EvalError: Refused to evaluate a string as JavaScript because ‘unsafe-eval’ is not an allowed source of script in the following Content Security Policy directive: “script-src ‘self’ ‘unsafe-inline’”

I would like to enquire if the unsafe-eval is needed while running the application or is there a CSP we can follow?

The reason for this is because we are following a security best practice and one of the recommendation is to remove ‘unsafe-eval’ from the Content-Security-Policy

We have also recently upgraded to Rocketchat Version 6.10.0 and MongoDB Version 6.0.16 FYI

Careful you aren’t chasing ghosts.

Make sure all your domain setup is correct on both your Rocket server, and Apache.

Remember, on your proxy you can fudge just about anything you want.