Mitigate XSS Attacks with Content Security Policy

What is Content Security Policy?

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribution of malware.
Content Security Policy (CSP) - HTTP | MDN

XSS is still one of the most common web vulnerability – if someone else can run scripts on your site, it is not your site anymore.

Discourse mitigates XSS attacks with CSP, by allowing scripts only from trusted sources to load and execute. Discourse’s default policy employs a strict URL whitelist, and only allows sources that Discourse needs.

Currently, Discourse ships a CSP Level 2 policy with the following directives by default:

  • script-src specifies valid sources for JavaScripts
  • worker-src specifies valid sources for ServiceWorker scripts
  • object-src blocks the execution of plug-ins (Flash, Java, etc)
  • base-uri restricts the URLs for <base> element

The default policy will be expanded in future updates to include more directives.

Available Settings

  • content_security_policy: Turn on CSP (default on)

  • content_security_policy_report_only: Turn on CSP Report-Only mode (default off)

    CSP Report Only mode checks and reports the site’s violations, without blocking them. This can be used to experiment with different policies, and monitor their effects.

  • content_security_policy_collect_reports: Log CSP violations reports in /logs (default off)


  • content_security_policy_script_src: Extend the default script-src by defining additional whitelisted script sources

How to Turn on CSP?

Flip the content_security_policy site setting, and viola, CSP is on!

However, since CSP will start blocking any non-whitelisted script sources immediately, I recommend the following steps to make sure that CSP is not blocking your site’s customizations:

  1. Turn on CSP Report-Only mode, and check for CSP violations.
  2. Extend the default CSP as needed
  3. Turn on Full CSP.

Are My Customizations CSP-Compliant?

1. Inline JavaScripts in Themes / Components

It is very common to have inline JavaScripts in themes:

<script type="text/discourse-plugin" version="0.8">
  api.replaceIcon('heart', 'thumbs-up');

Even though Discourse’s default CSP does not permit them, inline JavaScripts in themes / components are automatically extracted into an external file, so there are no changes required!

2. Inline on Event Handlers

<a href="#" onclick="doSomething()">Foo</a>

Unfortunately, inline on event handlers (e.g onclick, onload, etc) are also considered as inline scripts. It is recommended to add event listeners via JavaScript.

Here is an example of refactoring the above code:

<a href="#" id="bar">Foo</a>

  // if the element is already in the DOM
  document.getElementById('bar').addEventListener('click', doSomething);

  // otherwise, try event propagation
  $('#main').on('click', '#bar', doSomething);

3. Tags Linking to External Resources e.g <script>

If your site’s customizations depend on third-party JavaScripts, you may either

  1. Copy and paste the script content into your theme / component, or
  2. Extend the default CSP by whitelisting the source.

4. Third-Party Script / Service Integration

Different integrations will have different requirements, but can be addressed similarly.

You could look up the integration’s recommended CSP whitelist, and extend the default CSP accordingly. I suggest simply turn on CSP Report Only mode in Discourse, and watch your console to determine which resources you’ll need to whitelist to make your integrations work.

This is especially important when using third-party script bundlers like Google Tag Manager or Segment, because these bundlers can load many third-party or inline scripts. (For Segment, you might need to add 'unsafe-inline' to support inline scripts. For GTM, Discourse uses the recommended nonce approach which includes inline script support in GTM custom templates.)

Extending the Default CSP

1. Via Site Setting

Admins can extend their site’s CSP by defining additional script sources to be whitelisted in the content_security_policy_script_src site setting. They can whitelist scripts individually with the full source path, or if the source is trusted, cover all scripts under the base URL:

You can extend script-src with all valid source definitions, including hash-sources, and 'unsafe-inline' if you must.

2. In Plugins

If your plugin integrates or depends on third-party JavaScripts, you may extend the default CSP in plugin.rb with the extend_content_security_policy API.

# plugin.rb
  script_src: ['', ''],
  object_src: ['']

3. In Themes and Components

Define a list-type theme setting named extend_content_security_policy:

# settings.yml
  type: list
  default: "script_src:|script_src:"

And this is what it will look like in the UI:


I can no longer access my site due to a bad CSP setting, what should I do?

You will need SSH access to your site, and open the Rails console with:

cd /var/discourse
./launcher enter app
rails c


SiteSetting.content_security_policy_script_src = ""

This will reset your CSP setup back to default, and you should be able to get back to your site.

Additional Resources


I added a note about this to our public file :tada:


As of this commit, we’ve turned off CSP violations reports by default because the vast majority of the reported violations are false positives.

To illustrate this, here is a screenshot of logs from a site running Discourse with CSP enabled and reporting enabled (filtered using “CSP Violation”):

All of the reported violations are not related to the site’s code:

  • violations with ‘’ or ‘’ in the URL have nothing to do with Discourse, they’re likely coming from a browser extension
  • the Google Analytics violation reports are also not legitimate. They are triggered by Firefox in privacy mode, or Firefox with a privacy extension enabled (like DuckDuckGo Privacy Essentials).
  • Violations with ‘inline’, ‘data’ or ‘about’ are triggered by extensions as well. It’s not shown in the screenshot above, but these violations have some more details in the env tab of the log. In there, under script-sample, some of these violations had code like BlockAdBlock or window.klTabId_kis or AG_onLoad, which come from the AdBlock, Kaspersky, and AdGuard extensions, respectively. (I found this repo: very useful in helping explain some of these reports.) Some of these violations will have safari-extension or user-script in the source-file variable (again, in env), so that points to Safari extensions as the culprit for the violation.

In other words, there’s a lot of noise in CSP violation reports, so it’s not useful to log them at all times. They might be helpful while you are configuring CSP, but the reporting should be off during the normal operation of a site.

A few final notes: if you site is using a tag manager (like Google Tag Manager or Segment) you need to load the site in your browser, and carefully examine the violations in the console. These tools load third-party scripts from third-party domains and/or inline scripts so you need to carefully whitelist each of them using the source URL or the hash of the inline script (Chrome usefully includes the hash of inline scripts in the console error statement).

If your site uses an advertising service (like Google Ad Manager, Adsense, etc.) you probably will have to use a very permissive policy:

In the screenshot above, the policy allows any script from a https: source and any inline script. (In the future, this might be replaced by the strict-dynamic keyword, but as of this writing, strict-dynamic isn’t supported by Safari or Edge.)


8 posts were split to a new topic: Protocol-less CDN URLs are problematic

Please note that Safari doesn’t understand some parts of CSP, and this is normal:

You can safely ignore the CSP errors in Safari, you’ll see those on all sites, it just means Safari doesn’t understand worker-src and report-sample .

I guess we need to wait for Safari to be updated?


I’m having trouble configuring, which recommendation?

my forum:

link: White blank advertisement


It depends on what URLs your ads are requesting. You can look at your browser’s console to see them.

See also the relevant section from the OP:


this solves the problem of the error


Could you please add a Feature-Policy?

This is the one that I am using for more than a year now. (host nginx)

add_header Feature-Policy “geolocation ‘none’; midi ‘none’; notifications ‘self’; push ‘none’; sync-xhr ‘none’; microphone ‘none’; camera ‘none’; magnetometer ‘none’; gyroscope ‘none’; speaker ‘none’; vibrate ‘none’; fullscreen ‘none’; payment ‘none’;”;

Would it make sense to add the following to Content-Security-Policy header? This is what I am successfully using (added by host nginx, on top of discourse built-in CSP):

default-src 'none'
style-src 'self' domain 'unsafe-inline'
img-src https://* data: blob: 'unsafe-inline'
font-src 'self' domain
connect-src 'self' domain
manifest-src 'self' domain

Given that the spec is still a draft, I don’t expect us to implement it at this time. The Mozilla website you listed even says:

The Feature-Policy header is still in an experimental state, and is subject to change at any time. Be wary of this when implementing Feature Policy on your website.


vibrate 'self' - likes on Android trigger a faint, brief vibration.


I just installed discourse 2.6.0.beta1 . Do i need to reconfigure this? Thank you

1 Like

You do not, this is on by default. You only need to modify the config if you’re seeing external resources that are being blocked and you want them to run.


I am running 2.6.0 beta 2.

I use the following services in the forums:

  • Google Tag Manager
  • Google Ad Manager
  • Google Ad Sense

Currently, I am using report CSP only while I try to resolve all open issues.

Here are my CSP settings:

With the current settings, I am still receiving LOTS of CSP errors. Some seem like they can be ignored. However this one is boggling me as I have domain declared in the CSP settings.

Am I missing something?

CSP Violation: ''


/var/www/discourse/app/controllers/csp_reports_controller.rb:9:in `create'
actionpack- `send_action'
actionpack- `process_action'
actionpack- `process_action'
actionpack- `block in process_action'
activesupport- `block in run_callbacks'
/var/www/discourse/app/controllers/application_controller.rb:340:in `block in with_resolved_locale'
i18n-1.8.5/lib/i18n.rb:313:in `with_locale'
/var/www/discourse/app/controllers/application_controller.rb:340:in `with_resolved_locale'
activesupport- `block in run_callbacks'
activesupport- `run_callbacks'
actionpack- `process_action'
actionpack- `process_action'
actionpack- `block in process_action'
activesupport- `block in instrument'
activesupport- `instrument'
activesupport- `instrument'
actionpack- `process_action'
actionpack- `process_action'
activerecord- `process_action'
actionpack- `process'
actionview- `process'
rack-mini-profiler-2.0.4/lib/mini_profiler/profiling_methods.rb:78:in `block in profile_method'
actionpack- `dispatch'
actionpack- `dispatch'
actionpack- `dispatch'
actionpack- `serve'
actionpack- `block in serve'
actionpack- `each'
actionpack- `serve'
actionpack- `call'
/var/www/discourse/lib/middleware/omniauth_bypass_middleware.rb:68:in `call'
rack-2.2.3/lib/rack/tempfile_reaper.rb:15:in `call'
rack-2.2.3/lib/rack/conditional_get.rb:40:in `call'
rack-2.2.3/lib/rack/head.rb:12:in `call'
/var/www/discourse/lib/content_security_policy/middleware.rb:12:in `call'
/var/www/discourse/lib/middleware/anonymous_cache.rb:336:in `call'
rack-2.2.3/lib/rack/session/abstract/id.rb:266:in `context'
rack-2.2.3/lib/rack/session/abstract/id.rb:260:in `call'
actionpack- `call'
actionpack- `block in call'
activesupport- `run_callbacks'
actionpack- `call'
actionpack- `call'
actionpack- `call'
actionpack- `call'
logster-2.9.3/lib/logster/middleware/reporter.rb:43:in `call'
railties- `call_app'
railties- `call'
/var/www/discourse/config/initializers/100-quiet_logger.rb:19:in `call'
/var/www/discourse/config/initializers/100-silence_logger.rb:31:in `call'
actionpack- `call'
actionpack- `call'
/var/www/discourse/lib/middleware/enforce_hostname.rb:22:in `call'
rack-2.2.3/lib/rack/method_override.rb:24:in `call'
actionpack- `call'
rack-2.2.3/lib/rack/sendfile.rb:110:in `call'
actionpack- `call'
rack-mini-profiler-2.0.4/lib/mini_profiler/profiler.rb:200:in `call'
message_bus-3.3.1/lib/message_bus/rack/middleware.rb:61:in `call'
/var/www/discourse/lib/middleware/request_tracker.rb:176:in `call'
railties- `call'
railties- `public_send'
railties- `method_missing'
rack-2.2.3/lib/rack/urlmap.rb:74:in `block in call'
rack-2.2.3/lib/rack/urlmap.rb:58:in `each'
rack-2.2.3/lib/rack/urlmap.rb:58:in `call'
unicorn-5.6.0/lib/unicorn/http_server.rb:632:in `process_client'
unicorn-5.6.0/lib/unicorn/http_server.rb:728:in `worker_loop'
unicorn-5.6.0/lib/unicorn/http_server.rb:548:in `spawn_missing_workers'
unicorn-5.6.0/lib/unicorn/http_server.rb:144:in `start'
unicorn-5.6.0/bin/unicorn:128:in `<top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `load'
/var/www/discourse/vendor/bundle/ruby/2.6.0/bin/unicorn:23:in `<main>'

Env 1:

hostname	forums-web-only
process_id	27127
application_version	f2e14a3946b020ace5a368614f0da198cd17aa32
REQUEST_URI	/csp_reports
HTTP_USER_AGENT	Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:80.0) Gecko/20100101 Firefox/80.0
time	1:44 pm

Env 2:

hostname	forums-web-only
process_id	27161
application_version	f2e14a3946b020ace5a368614f0da198cd17aa32
REQUEST_URI	/csp_reports
HTTP_USER_AGENT	Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
time	1:39 pm

Env 3:

hostname	forums-web-only
process_id	27111
application_version	f2e14a3946b020ace5a368614f0da198cd17aa32
REQUEST_URI	/csp_reports
HTTP_USER_AGENT	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36
time	12:16 pm

There are lots and lots of false positives in CSP reporting. See my reply above for more details.

You don’t need most of the rules you have set in your screenshot, just https: and unsafe-inline are enough, they allow all scripts starting with https and all inline scripts. Try cleaning up your CSP sources setting and enabling CSP (without reporting), it should work.


Hi just wondering, the Content-Security-Policy: frame-ancestors ‘none’ directive is one that “will be included in future updates” as mentioned by the OP?

Is it possible to add that directive somehow or should I just wait and not worry about it. Was just doing a hardening exercise and this was the only open item / recommendation by that online security tool. Gives me a lot of confidence in the platform actually, great job guys!


I’m not sure – what do you think @xrav3nz?


I’d say don’t worry about it for now.

frame-ancestors is similar to X-Frame-Options header which Discourse/Rails already enforces. The header is currently set to sameorigin – roughly the same as the CSP directive’s self option.

IMO we won’t gain much from implementing frame-ancestors right now, unless we need to support whitelisting specific domains other than self.


I agree with this.

Chasing every possible vulnerability scanner “issue” can end up breaking things which are important, for a very little risk-benefit ratio.

There are a lot of “vulnerabilities in theory” which are rarely exploited or can only be exploited under a very specific scenario. These types of potential vulnerabilities have never been exploited on a Discourse site, to my knowledge; and I would advise against “fixing” things which are “in theory’” a vulnerability that have not resulted in a breach of any consequence.

That’s my 2 cents as a many decades long cybersecurity professional. I am happy to discuss the basics of cybersecurity risk management if anyone is interested.


We just landed support for CSP frame-ancestors directive. It’s disabled by default for now behind the content security policy frame ancestors site setting. You can add domains to the list using via /admin/customize/embedding as always.

This directive will be enabled by default in the next release cycle.