Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Will MyBB support default-src 'self' in CSP?
Hi, we've been running a MyBB forum for about 5 years - thanks!

Over the past year based on the recommendation by Google and Mozilla to migrate websites to HTTPS, I've been gradually implementing all of the recommendations of the MyBB "Setting Up HTTPS" document:

We have an SSL certificate provided by our webhost, and my htaccess file looks like this:

# Force HTTPS
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

# Set Secure HTTP Headers
Header always set Strict-Transport-Security "max-age=15768000; includeSubDomains; preload;" env=HTTPS
Header always set Content-Security-Policy "default-src 'self' https: data: 'unsafe-inline' 'unsafe-eval' ; frame-ancestors 'self'; upgrade-insecure-requests; base-uri 'self'; reflected-xss block;"
Header always set X-XSS-Protection "1; mode=block;"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin"

# Hide this file
<Files .htaccess>
order allow,deny
deny from all

# If a folder does not contain an index file, do not display content to browser
Options -Indexes

With this I've finally scored a "B" on and

However, the reports conclude that the Content Security Policy settings required for MyBB are basically insecure, specifically the need for data: 'unsafe-inline' and 'unsafe-eval' to allow inline styles and scripts

So, my long question is this: Will MyBB 1.9 allow us to restrict the default-src, script-src, object-src (etc) settings to 'self' ?

It's not clear yet. I'd love to give a definitive answer, but I honestly haven't looked into it at all yet - we'd need a way to replace the reasons that we currently use inline JS and styles (namely, getting PHP data into JS/CSS).
Thanks, Euan,

Google mentions "if you must..." about typical forum software being built on inline scripts with an example that echoes what you said

Apparently going forward, to be fully compliant, you can specify inline with a "nonce" or a "hash" (from the same article):

The recommended MyBB security settings found here...

...result in this from the CSP evaluator (link below):

Further reference for anyone interested - this is all about the HTTPS SSL/TLS lock on the browser, and making sure the connection is standards compliant and as secure as possible...

Mozilla's HTTPS and Content-Security-Policy guidelines

Scott Helme's CSP Cheat Sheet

Create and test website https and CSP headers:
I'll certainly look int it and see what we can do to improve Smile
(07-31-2019, 06:52 PM)gimbal Wrote: Thanks again - I appreciate the info you all provide about MyBB here.

Do you happen to know anything about the other MyBB security recommendations - specifically the HTTPS and Header set Content-Security-Protocol (CSP) directives?

To function with a CSP header, MyBB requires allowing default-src 'unsafe-inline' 'unsafe-eval' directives (to allow inline scripts), but apparently that basically defeats the purpose of having CSP? Just wondering if there is a roadmap to getting MyBB to comply with default-src 'self' which would be considered safer? Or, is this not really an issue?
(07-31-2019, 07:01 PM)gimbal Wrote: Google mentions that "if you must..." about typical forum software being built on inline scripts with an example that echoes what you said

Apparently going forward, to be fully compliant, you can specify inline with a "nonce" or a "hash" (from the same article):

Yes, ideally it would be possible to disallow all inline <script>s which would mitigate complete classes of vulnerabilities.

As Euan says, there are currently hundreds of tags being included in the source code of various pages - it's possible to pass necessary data to included .js scripts, but a significant amount of such JavaScript code will require logic changes in related areas.
We'll likely start indexing all those locations and choose the best approach at some point, but it's not tied to any specific future MyBB version yet.

Meanwhile, the current Content-Security-Policy example mainly adds HTTPS-related improvements for upgrading and blocking unsecured requests. These directives should be safe to add on most MyBB installations, and similarly, depending on installed themes and plugins (what kinds of resources, and from what kinds of locations, they use), additional restrictions may be added. (DF3A 34D9 A627 42E5 BC6A 6750 1F2F B8AA 28FF E1BC) ▪
Hi again, I am wondering if the example below from Github is a possible solution for adding "nonces" (Numbers Used Once) to the inline scripts and styles MyBB uses? ... with the ultimate goal of protecting MyBB with Content Security Policy, by using script-src "nonce" directives, instead of "unsafe-inline" ?

Background: Content Security Policy is about protecting websites and visitors, by blocking everything first, and then "whitelisting" only the resources that are needed. But forum software uses a lot of inline scripts and styles - So to use MyBB with a CSP, you have to specify a script-src of "unsafe-inline" that effectively opens back up much of the vulnerabilty that CSP is meant to block.

The recommended solution is to use "nonces" (Numbers Used Once) that are generated on each page request, and are inserted in to each page header as a CSP directive, and also in to the inline script or style tags, and they must match on each request for any script to run. Any attacker would have a very hard time guessing the nonce to insert their own script. The challenge is how to generate, insert, and verify the nonce reliably.

Here's an example I found on Github for Kirby software -


  $csp_nonce = base64_encode(random_bytes(20));
  $csp_header = "Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-" . $csp_nonce . "';";
  c::set('csp-nonce', $csp_nonce);


<script type="text/javascript" nonce="<?= c::get('csp-nonce') ?>">
  console.log('Hello World!')
Something similar to that would work, yes.

Forum Jump:

Users browsing this thread: 1 Guest(s)