EE and Content Security Policy
Development and Programming
I’ve been experimenting with Content Security Policy (CSP) on a major website that’s running on EE 2.7.3 and found that, in order to keep the CMS operational, I’m having to make the following concessions:
- allowing both ‘unsafe-inline’ and ‘unsafe-eval’ on script-src
- allowing ‘unsafe-inline’ on style-src
- allowing data: on default-src
- allowing data: on font-src
…all of which are considered bad practices when protecting against cross-site scripting. The first two bullets are necessary just to get the login screen operational, and the latter two for any editing window.
My questions are:
1) Is this issue addressed in any way in later versions of EE? A Google search returns nothing and the Ellis Lab website isn’t using CSP, so I’m guessing not.
2) CSP functions through page headers, is there a way through .htaccess to issue different headers (i.e. a different set of policies) to the admin.php file and the rest of the backend so that I can improve security elsewhere?
There are wildly varying opinions on where code should be called and executed, and v2.7.3 is very old (Dec 2013), and built on a CP designed in 2009. Quite a few things have changed in web dev since then. So there are some techniques in newer versions—particularly v3—that aren’t employed anymore.
In general though, we don’t trust the browser or the environment to provide security. They are great measures that can be useful, but are not part of our development or auditing process. They are more useful for your front-end, where you control the markup and intend to limit the scope of user interaction with your site.
The best practice for keeping your control panel secure is keeping your software up to date, and only running trusted third-party add-ons. There are far more issues in running code that has not been updated in many years than there is in relaxing browser-based security policies. Hope that helps!
Edit-add: Oh and for your second question, a <filesMatch> block should allow you to branch custom headers in a shared .htaccess. Ref: https://httpd.apache.org/docs/2.4/mod/core.html#filesmatch.
Thanks, Derek.
I’m certainly not expecting 2.7.3 to be future-proof, I was just curious to see if someone would chime in by saying they didn’t have to make any of those exceptions 3.x.x. After getting handed the keys from the developer it’s taken us a while to get a handle on how to develop with this version of EE and I expect that an update is going to break a lot of things that took significant effort to stabilize.
Anyway, CSP is just one of several security measures we’ve implemented or will implement, and it has the scent of something whose absence could be penalized by Google or the browser makers in the near future. It’s also something that can be implemented pretty quickly, even on a large website with a dozen content sources across its pages such as ours.
Your <filesmatch> suggestion worked great, and for those curious here’s some example code that allowed me to target the front and back ends of our site with different policies:
<IfModule mod_headers.c>
<FilesMatch "(admin\.php)$"> # for ExpressionEngine
Header set Content-Security-Policy: "default-src ...rest of policy"
</FilesMatch>
<FilesMatch "(?<!admin\.php)$"> # for Public-Facing Website
Header set Content-Security-Policy: "default-src ...rest of different policy"
</FilesMatch>
</IfModule>it has the scent of something whose absence could be penalized by Google or the browser makers in the near future
I agree that seems likely, though Google shouldn’t ever be in your control panel, and there are some actions that an administrator of a CMS is going to take that will always look naughty from a security standpoint. Submitting POST with all manner of HTML and JS, for instance. So I think you’ve hit the perfect balance in your .htaccess, do you mind if I share that with the rest of our users in the docs? Thanks!
[D]o you mind if I share that with the rest of our users in the docs?
Not a problem at all.