A hint: This file contains one or more very long lines, so maybe it is better readable using the pure text view mode that shows the contents as wrapped lines within the browser window.
We take security very seriously at Discourse. We welcome any peer review of our 100% open source code to ensure nobody's Discourse forum is ever compromised or hacked.
In order to give the community time to respond and upgrade we
strongly urge you report all security issues privately. Please use our
program at Hacker One to provide details and repro steps and we will
respond ASAP. If you prefer not to use Hacker One, email us directly at
firstname.lastname@example.org with details and repro steps. Security
issues always take precedence over bug fixes and feature work.
We can and do mark releases as "urgent" if they contain serious security
For a list of recent security commits, check our GitHub commits prefixed with SECURITY.
Discourse uses the PBKDF2 algorithm to encrypt salted passwords. This algorithm is blessed by NIST. Security experts on the web tend to agree that PBKDF2 is a secure choice.
options you can customize in your production.rb file
pbkdf2_algorithm: the hashing algorithm used (default "sha256")
pbkdf2_iterations: the number of iterations to run (default 64000)
The main vector for XSS attacks is via the post composer, as we allow users to enter Markdown, HTML (a safe subset thereof), and BBCode to format posts.
There are 3 main scenarios we protect against:
Markdown displayed on the page invokes an XSS. To protect against client side preview XSS, Discourse uses xss.js in the preview window.
CSP is on by default for all Discourse installations as of Discourse 2.2. It can be switched off in the site settings, but it is default on.
On the server side we run a allowlist based sanitizer, implemented using the Sanitize gem. See the relevant Discourse code.
In addition, titles and all other places where non-admins can enter code are protected either using the Handlebars library or standard Rails XSS protection.
CSRF allows malicious sites to perform HTTP requests in the context of a forum user without their knowledge -- mostly by getting users who already hold a valid forum login cookie to click a specific link in their web browser.
Discourse extends the built-in Rails CSRF protection in the following ways:
By default any non GET requests ALWAYS require a valid CSRF token. If a CSRF token is missing Discourse will raise an exception.
API calls using the secret API bypass CSRF checks.
Certain pages are "cacheable", we do not render the CSRF token
<meta name='csrf-token' ...) on any cacheable pages.
Instead when users are about to perform the first non GET request they
retrieve the token just in time via
If you install via our recommended Docker image in our install guide, nginx is the front end web server. For additional DDOS protection we recommend placing HAProxy in front.
We strongly recommend that the various Discourse processes (web server, sidekiq) run under a non-elevated account. This is handled automatically if you install via our recommended Docker image -- see our install guide for details.