Jump to content
Andreas Faust

ProcessWire and Content Security Policy (CSP)

Recommended Posts


the ProcessWire-login-page uses an inline-script in the head-tag (defining the variable "ProcessWire"), which Content Security Policy doesn’t allow. 

Is there a way to fix this? Or does PW generally exclude CSP?

Share this post

Link to post
Share on other sites

Inline scripts are used widely in the admin interface, so this sounds like a case where you wouldn't want to enable CSP. It's fine to enable it on your front-end if it's something you want, or you could use the unsafe-inline keyword to get past this issue, though.

CSP is well-intentioned, but some of it's rules don't make that much sense in certain use cases, and our admin interface is in my opinion one of those cases. On the other hand ProcessWire doesn't dictate any of the markup you see on the front-end of your site :)

Note: this topic has been moved to the security forum.

  • Like 3

Share this post

Link to post
Share on other sites

Thank you for the quick reply, teppo.

So I’ll use only a meta-tag in the head of my template-files, instead writing a directive in PW’s .htaccess-file.

But I don’t understand, why CSP doesn’t make sense for the PW-backend. I tried it out by simply creating a (hardcoded) nonce for the described inline-script and the backend seems to work (on a basic level). Wouldn’t this (done with a real nonce, of course) improve PW’s security?

Share this post

Link to post
Share on other sites

I'm mainly thinking about the way ProcessWire makes it possible for third party modules to alter the source of a page, inject their own scripts or styles, etc. While this does require a lot of trust in installed modules, it's also something we wouldn't want to disallow. Inputfields are another thing consider: many third party inputfields rely on existing libraries, in which case the implementation details are more or less out of our hands.

Unless I'm missing something obvious, CSP would mostly be useful if users were able to inject their own scripts or styles for other users to see. In order to do that, you'd either have to be a superuser and use some rather specific features to achieve this, or exploit a third party module that allows this. Latter option is absolutely something to consider, but the first one not that much: generally speaking we consider users with access to the admin interface "trusted"... and superusers even more so.

While we could introduce a method of "registering" embedded content with the system, I'm not entirely sure if that's worth it. It could make the lives of perfectly legitimate developers more difficult, while the benefits are — in my opinion — somewhat questionable. It's also good to keep in mind that this isn't something that would protect you from malicious / hacked third party modules: a module could simply hook into an earlier (or later) point in program execution and override any CSP rules you've got in place.

That being said, I'm not against the idea of implementing this as a configurable option. It would no doubt be possible for ProcessWire to generate nonces for any inline content it requires, and as long as this would be a configurable setting, it shouldn't come as much of a surprise if some third party features stopped working afterwards. I don't see this as such a big thing and I'd imagine the potential use cases to be limited, I for one would be OK with this as long as it doesn't needlessly complicate things 🙂

  • Like 5

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By Chris Bennett
      Plenty of posts on the forum relating to Content Security Policy (CSP) and how to integrate it with Processwire.
      It's not too hard to implement a decent htaccess CSP that will get you a solid B+ at Mozilla Observatory.
      If you're after A+ it's a little harder because of all the back-end stuff... until you realize it's surprisingly easy.
      After a lot of testing, the easiest way I found was to specify only what is needed in the htaccess and then add your required CSP as a meta in your page template.
      Plenty of people have suggested similar. Works very easily for back-end vs front-end, but gets complicated if you want front page editing.
      Luckily, a little php will preserve back-end and front page editing capabilities while allowing you to lock down the site for anyone not logged in. 
      None of this is rocket science, but CSPs are a bit of a pain the rear, so the easier the better, I reckon 😉
      The only CSP I'd suggest you include in your site htaccess is:
      Header set Content-Security-Policy "frame-ancestors 'self'" The reason for this is you can't set "frame-ancestors" via meta tags.
      In addition, you can only make your CSP more restrictive using meta tags, not less, so leaving the back-end free is a solid plan to avoid frustration.
      Then in your public front-facing page template/s, add your desired Content Security Policy as a meta tag.
      Please note: your CSP should be the first meta tag after your <head>.

      For example:
      <!DOCTYPE html> <html> <head> <meta http-equiv="Content-Security-Policy" content="Your CSP goes here"> <!-- followed by whatever your normal meta tags are --> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <meta name="format-detection" content="telephone=no"> If you haven't got Front Page Editing enabled, this works fine by itself.
      Just one extra step is needed to make sure you don't have to worry either way. 
      The easiest way I found to allow both CSP and front page editing capabilities is the addition of a little php, according to whatever your needs are.
      Basically, if the user is a guest, throw in your CSP, if they're not do nothing.
      It's so simple I could have kicked myself when it finally dawned on me.
      I wish it had clicked for me earlier in my testing, but it didn't so I'm here to try to save some other person a little time.
      <!DOCTYPE html> <html> <head> <?php if ($user->isGuest()): ?> <meta http-equiv="Content-Security-Policy" content="Your CSP goes here"> <?php endif; ?> <!-- followed by whatever your normal meta tags are --> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1"> <meta name="format-detection" content="telephone=no">  
      If you want it a bit more involved then you can add additional tests and be as specific as you like about what pages should get which CSP.
      For example, the following is what I use to expand the scope of the CSP only for my "map" page:
      <?php $loadMap = $page->name === "map"; ?> <!DOCTYPE html> <html> <head> <?php if ($user->isGuest()): ?> <meta http-equiv="Content-Security-Policy" content="default-src 'none'; base-uri 'self'; manifest-src 'self'; form-action 'self'; font-src 'self' data: https://fonts.gstatic.com; frame-src 'self' https://www.youtube.com; img-src 'self' data:<?php echo ($loadMap) ? " https://maps.googleapis.com https://maps.gstatic.com" : ""; ?> https://www.google-analytics.com; script-src 'self' <?php echo ($loadMap) ? "https://maps.googleapis.com " : ""; ?>https://www.google-analytics.com https://www.googletagmanager.com; style-src 'self' <?php echo ($loadMap) ? "'unsafe-inline' https://fonts.googleapis.com" : ""; ?>"> <?php endif; ?>  Hope this saves someone a little time testing.
    • By opalepatrick
      Hi there, wondering what others are thinking about CSP. I came a cropper after implementing it on a pw site of mine (as per 
      but I do think that it makes a lot of sense and was disappointed to be demoted from an A+ to a D at https://observatory.mozilla.org after ripping it out to make my site admin work again. Any thoughts?
  • Create New...