Several years ago we added support to ShieldPRO for an emerging technology called Content Security Policy [CSP]. We were excited about this new feature and the huge benefits it could bring to visitor-side security.
Unfortunately with ShieldPRO v10.2, we’ve decided to completely remove many of these CSP options from the plugin, for reasons we’ll outline below.
PHP-Based Content Security Policy Headers Are Problematic
If you’ve been with us for any length of time, you’ll know our feelings on Page Caching – we really don’t like it applied to WordPress. Of course, caching in-and-of-itself isn’t bad, but set-it-and-forget-it page caching is horrific, and unfortunately pervasive.
Nearly all page caching plugins that we’ve examined ignore most HTTP Headers sent by WordPress.
So when you combine Shield’s HTTP Headers with Page Caching, you don’t get what you might expect. In-fact, you get no headers from Shield at all.
Furthermore, there’s nothing at all that we can do to fix this. This is the responsibility of the caching plugin developers.
I wish the situation was different – if we could fix it, we would.
So what’s the problem?
We have to support it. The load on our support system for HTTP Headers alone is terrible. We have documentation, but many don’t care for that.
So this is 1 reason we’re looking to drop Content Security Policy altogether from Shield.
Plugin Conflicts With CSP Headers Don’t Appear In The Audit Trail Logs
This problem occurred more recently when the Divi theme developers released an update that essentially broke under the influence of Content Security Policy headers.
It’s a strange one, and it took us a long time to dig to the bottom of.
CSP Headers are only sent to the browser on the front-end i.e. what website visitors see (not the WP admin).
So customers would come to us and say: “Using the Divi editor doesn’t work when Shield is active, but when we disable Shield, it works!”.
That’s great that the customer has found the source of the conflict, so we say:
“Please reproduce the error and immediately check the audit trail for anything that’s getting blocked”.
The client responds:
“Nope, nothing in the audit trail.”
That is until we get access to a client site and discover the horrible truth – Content Security Policies are being violated and so the Divi editor breaks.
Conclusion: Content Security Policy headers from Shield is breaking normal functionality in the WP Admin and we have no way to offer reliable client support.
Why Shield’s CSP Implementation Is A Fail
Content Security Policies is a vast topic and quite complex. When we first implemented it within Shield, we’d hoped to build upon it, but over time we realised that this would be a huge undertaking… and we just never got to it.
We believe CSP headers demands a dedicated plugin all to itself. It’s a huge area and our implementation just doesn’t do it justice at all.
Some customers have told us this in the past, but we’d hoped that by keeping it in there, it’d help some admins. But it’s causing more harm than good right now.
As you know, website security isn’t a “set it and forget it” task. But our CSP implementation is structured a bit like that. Some Shield users were checking all the CSP options and assuming that Shield would do all the work. We wish it would, but unfortunately with CSP complexity as it is, it wont work like that.
Custom CSP Rules Is Still Available
Some time ago (ShieldPRO 8.7) we added the option to provide completely custom Content Security Policy headers.
We’ve decided to keep this only this option available and remove all others.
This will allow admins who understand CSP to implement their own rules.
We want to make it clear, however, that we don’t offer support for the creation and maintenance of your CSP rules. You’ll need to dig into CSP yourself, or consult with a web developer, to get these working for your particular circumstances.
And of course, if you use Page Caching, we can’t guarantee they’ll work as you expect at all.
When Will We Remove CSP Options?
From Shield 10.2 onwards, all options pertaining to Content Security Policy rules will be removed, except the custom rules section.
Comments and Feedback
It’s never a good time to remove a feature from Shield, but I trust after our explanation of the issues we’re all facing, you’ll understand why we have to remove it.
Security is hard enough to get right, but security options that just cause more trouble than good can’t be beneficial to anyone.
Of course, please let us know if you have any thoughts on the points we’ve raised today – we take your feedback onboard and depending on our development capacity in the future, we may yet return to CSP HTTP Headers.