coderars

Sorry, I wasn’t aware of some important things. Now I understand, so my real problem is that the logic behind the GDPR cookie consent plugin I use is to generate custom CSP headers for every visitor based on his chosen cookie consent settings to allow/block linked resources (js/css/etc). E.g. if the visitor disallows marketing cookies then those javascript resources won’t be allowed in his custom CSP header so they will be blocked.

Because it’s totally dynamic, there’s no way to store it in the cache. As for the feature request, the only solution I can imagine is adding some check in advanced-cache.php which looks for a (pre/user)defined php file, and if it exists, it runs that before sending out the cached page. In that file, I could generate and send the CSP header or do whatever customizations. But it’s just a sudden idea…

My server is well optimized, but it was nice to have ~20ms response times with static HTML caching. Nginx can do this native with FastCGI cache but unfortunately, this wasn’t the first time static caching made me trouble. The speed it gives just not worth the risks, so I’m rather going to avoid using them.

@jonkastonka sorry, I was wrong and misleading about my caching problem ?? Using the meta tag won’t fix it either. The problem is more complex, unfortunately, the cache-enabler plugin (and probably some other similar solutions) blocks this plugin’s CSP logic: generating a custom CSP header for every visitor based on his stored cookie consent settings to block/allow loading resources.

With an empty cache, cache-enabler stores the WHOLE response of the ongoing request, and after that, the following visitors will be served with that cache without fully (or even) loading WordPress. So CSP meta won’t be actualized for the current visitor. The same is true for the default php header() setting because that won’t run at all.

Also, there are caching plugins (cache-enabler, nginx-helper, etc) that can be configured with included webserver configs (example) to let the webserver directly send the cached content without running any php. Using these techniques kills the logic of this plugin ??

Placing it into that linked question would be enough I think.
Or maybe just a bit modification to the checkbox label:

Use meta. If your host blocks setting php header() or using static page cache, check this to add CSP as a meta tag in the header instead.

…or something like that.

Sure, that would solve the problem and I’m OK with that! The only advantage of my approach is that if you generate the link based on the ID of the selected page, then later changing the page’s URL (outside in page editor) won’t break the link (I guess) if the user forgets to actualize it in your plugin’s settings. But it’s not so dangerous, and it’s the user’s fault. Maybe the best would be your idea and mine together ?? Thank you!

Promise accomplished ??

Currently, I’m quite busy on other parts of my site but as soon as I turn back to well configure/customize this plugin I’ll write a detailed review I promise! ??

Superb! Thank you!

I think the switch in the plugin settings you mentioned is a safe idea until it’s not clearly investigated. However based on the links I sent I’m still unsure if the X header does anything at all in IE? (With the same value and without that sandbox flag) If not (my vote), then it could be safely removed (and without the need for that switch).

Here’s another one:
https://security.stackexchange.com/questions/191455/whats-the-alternative-of-content-security-policy-csp-header-in-internet-explo

Sure, however “IE 10-11 support sandbox only” and older versions knows nothing about CSP headers:

https://caniuse.com/contentsecuritypolicy
Known issues tab:

Partial support in Internet Explorer 10-11 refers to the browser only supporting the ‘sandbox’ directive by using the X-Content-Security-Policy header.

My local IE11 testing:
Currently there are some “Refused to load image” errors in console for my local dev site in Chrome (just for testing) but loading the same site in IE11 there’s no CSP error at all, so I assume the x-content-security-policy header is useless.