Http Headers disappearing with caching?

[Tarun80]

I may have found a possible bug?

I've been working on this for the past few days. So far, I've narrowed it down to the page cache. Somehow, when enabled, page cache stops http header security plugins from being recognized.

If I put the code into my htaccess file it works.

Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-Xss-Protection "1; mode=block"
Header always set X-Content-Type-Options "nosniff"

I also noticed under Page Cache that "Specify page headers" field is disabled. Not sure if that is related.

However, if I try using a plugin such as HTTP Headers it works for the initial page load. After that it doesn't.

I've been testing this with https://securityheaders.io/ and the Firefox Inspector.

Hope this information helps. Would be interesting to see these sort of security features added to W3 Total Cache Fixed.

[amiga-500]

Thanks for the info. I will sniff around in the coming days. Sounds fascinating. To save me time in recreating the same issue on my end, what http header security plugins were u using which are failing?

So to be clear you are:

1. Enabling an http header security plugin that inserts those security headers on outgoing responses
2. w3tc's page cache is enabled
3. When you view the responses on your browser those Headers aren't present
4. BUT, when you add them into your .htaccess file (which is what i currently do with the exact same 3 lines on my end) then it works fine.

As for the "Specify Page Headers" field being disabled. I can't remember exactly why frederick (the author) did that (it's been a while so my memory is hazy) but i believe it's only enabled when disk:basic is active. I believe it's because disk:enhanced is unable to store those details to disk since it gets its enhanced name from serving back cached pages very fast, vs. the basic which has to process the file (which stores those headers in the file too) before sending it back.

Having a new option to include security headers automatically into htaccess could be fairly quick to add into w3tc, but im still curious about those other plugins not working. I figure because when a request for a cache page comes in your htaccess redirects and serves back the html...so if those security plugins aren't modifying the htaccess directly (which i am surprised they dont do) then it wont ever serve those headers back. I'm figuring that is what is happening.

Anyway, adding the feature into w3tc is straight forward. It just would take a bit to create extra tweak features to allow users to decide what those headers should be. However, it seems virtually everyone always uses the same 3 security headers without much change so i could just have a single checkbox to just include these defaults:

Header set X-XSS-Protection "1; mode=block"
Header always append X-Frame-Options SAMEORIGIN
Header set X-Content-Type-Options nosniff

And then in time add more options to allow for better user tweaking to them

Cheers
Kimberly

Update

Sorry i just noticed you had mentioned above the plugin you were using: HTTP Headers. Thanks :)

[Tarun80]

Hi Kimberly,

I've also tried a couple other plugins that were a sort of all-in-one solution that also covered Content-Security-Policy and Public-Key-Pins.

I honestly forget what they were named as I removed them pretty fast. I do recall this Content Security Policy Pro as one I tried, though is unrelated to the issue.

Hope this helps.

[amiga-500]

From my tests it seems my assumptions were correct. It isn't a bug in w3tc but just how cache is working. In Disk Enhanced mode, cached pages purposely try to bypass as much wp activity as possible to feed back the cached results super fast. However, by doing that it prevents these security plugins from being able to attach their extra headers. So you'd only see these headers once, before the page is cached, and then subsequent cached requests will not show the headers again. This will only happen when using Disk Enhanced mode...not Disk Basic.

Because of that, either these security plugins should have a feature to place their headers in the htaccess file which surprisingly i can't find any that do that which is odd since it would speed up processing instead of having to run through its code on every request. Or, add similar security header feature options within w3tc.

So far, the only way i can get it working in w3tc's current form is to make use of Disk: Basic and then adding the following into the "Specify Page Headers" field (under Page Cache). Then it works fine because these security headers are then cached along with the page itself.

Content-Security-Policy
X-Content-Type-Options
X-Frame-Options
X-XSS-Protection

Anyway, just wanted to give you an update. At least you have a work around (inputting the necessary header fields into your htaccess). That is how i've been doing it for the longest time which also includes my Content-Security-Policy header too.

In the coming new year i probably will add the security feature into w3tc since its easy to do. The longest part is adding the nuance of customization capabilities to each.

[Tarun80]

Adding on another minor suggestion/addition: If possible, enhance cookie controls since W3TC Fixed handles cookies too. That way things like below can be handled via the plugin rather than adding code into functions.

@ini_set('session.cookie_httponly', true);
@ini_set('session.cookie_secure', true);
@ini_set('session.use_only_cookies', true);

Thanks and happy new year!

[amiga-500]

Sorry for the delay @Tarun80 ... i finally added a Security Headers section to W3TC. You can see it here: #344 with pix. It also includes the cookie enhancement parts you mentioned.

Currently the new feature is only for the v0.9.5.x users -- they told me i had to make v0.9.5.x a priority now; v0.9.4.x was previously my priority and then i did ports to v0.9.5.x later -- but I am porting this new feature over to the v0.9.4.x Generation soon (today/tomorrow) so if you're still interested in it, it will be in the next release.

I'm sure you already know, but just in case ... you will get an automatic update notification message (and ability to update) within WP (assuming you're using at least v0.9.4.6), so there is no need to come back here in search of when i push the next v0.9.4.x release.

Cheers
Kimberly

[Tarun80]

Thanks for the updates and followup.

Would you recommend switching to 0.9.5.x of W3TC Fixed? If so, precautions necessary or just drag and drop install over 0.9.4.x of W3TC Fixed?

[amiga-500]

Hi @Tarun80!

With Security Headers now officially in v0.9.4.6.3 of W3TC Fixed (btw, i assume WP successfully notified and allowed you to update to this new release on your site's admin page) i still intend to keep pushing fixes, updates, and new features for v0.9.4.x, it just might take me (or the others) a bit longer since our focus will be on v0.9.5.x. But anything new i add to v0.9.5.x will get ported to v0.9.4.x. Security patches will still be instantly pushed though. So you don't have to switch if you dont want to. I figure since everything is working proper on your end there is no point switching to v0.9.5.x.

And also, since v0.9.5.x doesn't have an automatic updater connected to this github repository yet compared to v0.9.4.x (i still havent ported that feature to v0.95.x), if you did switch you would have to check back here from time to time for an update which can be annoying. At least with v0.9.4.x the entire thing is automated and the notifications and updates are handled completely in WP. That alone, for me personally, i'd stick with v0.9.4.x.

Also our v0.9.5.x patch hasn't yet stripped out the advertisements and other bloat. So that could be another nuisance. Strangely, i recently discovered and fixed a bug in v0.9.5.x that was constantly tracking the user despite not giving permission to do so, and even when disabling it (which only gives the user that chance once every 30 days) it kept tracking anyway 😨

Btw, v0.9.4.x uses a different folder name (folder: w3-total-cache-fixed) compared to v0.9.5.x (folder: w3-total-cache) so if you did test out v0.9.5.x you would not touch your current v0.9.4.x but simply deactivate it and just install v0.9.5.x into a w3-total-cache folder. v0.9.5.x will use your current w3tc configs. If v0.9.5.x still brings your site down you'd deactivate and delete it in WP and reactivate v0.9.4.6.3.

Cheers
Kimberly

[daiky00]

@amiga-500 Does this work with cloudflare? I am using cloudflare it seems headers get remove I am not sure if is W3 cache or cloudflare?

[daiky00]

This my site btw https://www.anime-shop-online.com/

[marcoklompx]

I tried several options to add Security HTTP headers, but none of them work. FYI my setup is: Wordpress + W3TC + CloudFlare. I am using the latest version of Wordpress and W3TC. All other plugings are updated as well.

OPTION 1: Directly add rules to the .htaccess

<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=31536000" env=HTTPS
Header always set X-Frame-Options "SAMEORIGIN"
Header always set X-XSS-Protection "1; mode=block"
Header always set X-Permitted-Cross-Domain-Policies "master-only"
Header always set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "no-referrer-when-downgrade"
</IfModule>

These don't work and will be stripped somehow (W3 Total Cache or Cloudflare?). I added them at the top of the file at first (above W3 Total cache rules or below does not work).

OPTION 2: Add php code to functions.php
Added the following line of code to test before adding the rest:
header("X-XSS-Protection: 1; mode=block");

Checked on https://securityheaders.com directly which works and gives me a C-grade, but a few seconds later and it gives a D-grade again. Header is stripped again.

OPTION 3: Use a plugin
I used HTTP Headers to add the security headers (https://wordpress.org/plugins/http-headers/), those work well when you test them within the plugin, but not anymore when you load a live page.
Apparently W3 Total Cache blocks all those changes of this plugin, or other similar plugins... which I found out about here: #344

The setting in advanced settings does not work properly (500error), thus I cannot use it. This issue is described here: https://wordpress.org/support/topic/500-internal-server-error-after-setting-use-apache-mod_headers-to-send-header/. I am using the latest version, so I will contact them about it and hope they will fix it so that I can give that another try.

OPTION 4: Use W3TC build-in settings
So I found out that in W3 Total Cache you can now easily set these rules. It does add it to the .htaccess file, but nothing is actually working in my case.

Enabled:

• HTTP Strict Transport Security policy
• X-Frame-Options
• X-XSS-Protection
• X-Content-Type-Options

Whatever I try, something strips it and it gives me a D-score instead of an A-score if it just would add the headers :)

ARE THERE OTHER OPTIONS?
There is also the option to add it with CloudFlare workers: https://scotthelme.co.uk/security-headers-cloudflare-worker/. But that comes with a pricetag of $5 dollar/month if you would enable CloudFlare workers (and I am not sure of the solution works). But it should be possible with just W3TC, right?

@amiga-500 / anyone else: Hope you can help me with this issue.
@daiky00 I can see your site still has this issue as well, please let us know if you found a solution.