# How to relax Content Security Policy
**URL:** https://meta.discourse.org/t/how-to-relax-content-security-policy/244459
**Category:** Development
**Created:** [November 5, 2022, 4:51am UTC](https://meta.discourse.org/t/how-to-relax-content-security-policy/244459 "2022-11-05T04:51:32Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@titusc](https://meta.discourse.org/u/titusc)
#### Post date: [November 5, 2022, 4:51am UTC](https://meta.discourse.org/t/how-to-relax-content-security-policy/244459/1 "2022-11-05T04:51:32Z")
Hi
I’d like to do some testing of Discourse without necessarily going through its configured public domain name. For eg if Discourse have been installed and configured as [https://uat.mysite.com](https://uat.mysite.com) then I can obviously load my browser and browse to [https://uat.mysite.com](https://uat.mysite.com), which means my browser would exit my internal network out to public Internet to resolve the domain name to it’s public IP address, and load the pages via its public IP address.
I just tried browsing to Discourse via the internal IP address of the server (eg 192.168.1.2 shown below) and rightfully it doesn’t load because of Content Security Policy. The errors I’m getting are of the following form.
```plaintext
Refused to load the script 'http://192.168.1.2:12000/assets/locales/en-a9c88e45eb548bd7c807aecfd37d218891e213b5c1fd254857e0f16c72d73996.js' because it violates the following Content Security Policy directive: "script-src http://uat.mysite.com/logs/ http://uat.mysite.com/sidekiq/ http://uat.mysite.com/mini-profiler-resources/ http://uat.mysite.com/assets/ http://uat.mysite.com/brotli_asset/ http://uat.mysite.com/extra-locales/ http://uat.mysite.com/highlight-js/ http://uat.mysite.com/javascripts/ http://uat.mysite.com/plugins/ http://uat.mysite.com/theme-javascripts/ http://uat.mysite.com/svg-sprite/ 'sha256-rwfDVOTzygQmkOwFNAeX564B66beHoel4+gRLgQUgHg='". Note that 'script-src-elem' was not explicitly set, so 'script-src' is used as a fallback.
```
```plaintext
---------------------------------------------
| |
------------
uat.mysite.com resolves to 98.1.2.3 --> | Public IP | Server running Discourse. |
| 96.1.2.3. |
------------ |
| |
| ---------------- |
| | Private IP | |
| | 192.168.1.2 | |
---------------------------------------------
^
|
192.168.1.2 ------------------------------------------------------------
```
The reason why I’d like to access Discourse via the server’s internal IP is because I want to do testing. For eg if I want to load testing I don’t necessarily want to load up the network servicing the Internet. Or if I want to install a test instance on my laptop or a build server without necessarily setting up DNS.
I guess I can always override this by setting a custom entry in /etc/hosts but is there a way to either disable CSP or set it to trust other sources to permit testing?
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [November 5, 2022, 8:26am UTC](https://meta.discourse.org/t/how-to-relax-content-security-policy/244459/2 "2022-11-05T08:26:58Z")
> [@titusc](#):
>
> which means my browser would exit my internal network out to public Internet to resolve the domain name to it’s public IP address, and load the pages via its public IP address.
Then configure your machine to resolve that address to the local ip of the discourse server. There are many ways to do that, but they are os dependent, so you should include the os in your Google search. (In Linux and I think Mac is, you can just edit `/etc/hosts`.)
---
### Author:  [@titusc](https://meta.discourse.org/u/titusc)
#### Post date: [November 11, 2022, 3:16am UTC](https://meta.discourse.org/t/how-to-relax-content-security-policy/244459/3 "2022-11-11T03:16:48Z")
I actually tried /etc/hosts but still having the same error due to CSP. I’d have thought that there is a flag or setting that can be used to toggle this to enable the developers to do everything within their laptop without having to stand up a DNS solution. Looking at the [Install Discourse on macOS for development - documentation / developers - Discourse Meta](https://meta.discourse.org/t/install-discourse-on-macos-for-development/15772) it appears to bootstrap into something that works with [http://localhost:3000](http://localhost:3000) rather than an IP.
The challenge I have is I have automation to install Discourse and want to use the same process to stand up both development, UAT, and production environments and I don’t necessarily want to have the development environment accessible from the public Internet, which appears to be a requirement atm because it needs to resolve a proper FQDN. There are multiple use cases one of which is for eg automating the upgrade of Discourse in development environment every week and run a number of tests to see if anything breaks.
Anyway if there is a way of relaxing the requirement to allow direct access via IP it’d be good to know. Otherwise I guess the only other solution is to get a small DNS service going and then point the laptop to use the custom DNS service but it seems to be a bit of a hassle.
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [November 11, 2022, 5:34am UTC](https://meta.discourse.org/t/how-to-relax-content-security-policy/244459/4 "2022-11-11T05:34:14Z")
> [@titusc](#):
>
> is there a way to either disable CSP
There is a site setting named `content security policy`. You can uncheck and save to disable CSP.
As long as this is not done in production instance it’s okay.
---
### Author:  [@pfaffman](https://meta.discourse.org/u/pfaffman)
#### Post date: [November 11, 2022, 10:54am UTC](https://meta.discourse.org/t/how-to-relax-content-security-policy/244459/5 "2022-11-11T10:54:13Z")
> [@titusc](#):
>
> The challenge I have is I have automation to install Discourse and want to use the same process to stand up both development, UAT, and production environments
That’s not a good idea. It will never work. A development environment is necessity different as it has assets precompiled and a bunch of other stuff that makes development impossible. Unless you are developing plugins you don’t need a development environment at all. So if that’s the case then you can have your development environment be a docker install, it’s just not what would be called a development environment here.
You want to launch your staging and production environments using docker as described in the [standard install](https://meta.discourse.org/t/142537?silent=true).
---
### Author:  [@leonardo](https://meta.discourse.org/u/leonardo)
#### Post date: [November 11, 2022, 12:03pm UTC](https://meta.discourse.org/t/how-to-relax-content-security-policy/244459/6 "2022-11-11T12:03:13Z")
> [@titusc](#):
>
> I’d like to do some testing of Discourse without necessarily going through its configured public domain name.
Hi! I regularly do this, but with Docker installs. Assuming that you use our standard Docker installation in production, then for your acceptance testing you should be using the same thing. There is a wide margin for differences between dev and Docker installations (configuration, gem and JS package versions, etc) that can turn into migraines at deploy time.
Docker installations use and enforce HTTPS by default. Unless you want to customize the container template (which I’ve found has some hidden complexity), you can simply turn off HTTPS enforcing with another site setting.
This is my snippet for “relaxing security in a local Docker install”, which can just as easily be reverted before going to production:
```ruby
SiteSetting.content_security_policy = false
SiteSetting.force_https = false
```
Then it’s just a matter of your browser being able to find port 80 on the Docker container at `http://uat.mysite.com` – note that you’ll be using `http` instead of `https`.
For that, @pfaffman’s `/etc/hosts` trick is the way; details for each OS [here](https://www.howtogeek.com/howto/27350/beginner-geek-how-to-edit-your-hosts-file/).