Missing cache directives and https security headers

[accounts16]

As mentioned in this thread, as of this morning the issue seems to be resolved. And it was mentioned that some of them are set by Cloudflare, especially the HSTS and NoSniff. The others were directives from the caching plugin on the site.

I don’t expect you to resolve the caching plugin directives, just mentioned as part of the problem. How could I have been any more explicit about the 2 from Cloudflare not showing up?

I’m sorry that others did not choose to give the URL of their sites where they were also seeing the problem - I asked them to do so and can’t control that. But do know that they checked and verified the same issue I reported.

This issue went on long enough to knock all of these sites, and more, off the Chrome HSTS Preload list. So now we have to resubmit that.

Do you realize how reckless Cloudflare has been with what they roll out on the free plan and just how many site owners on that plan never even check their settings, much less their HTTPS security headers?

I do site audits for clients every week and there is something different in her constantly. No notification, no warning, nothing.

It costs time and money for me, my host, the WP Fastest Cache dev, and my clients to have to jump through hoops to verify the issue and determine the cause.

I checked every single setting in Cloudflare and could not find anything amiss. But we know for a fact that only free plan users had this issue, and that includes checking multiple sites on the same WHM hosting account that had a mix of free and Pro plans.

For any free plan issues, this forum is the only place to report. And we should not be subjected to ANYONE insulting us by calling us or our reports “sus”. Nor should we be subjected to providing info that did not even help verify the issue either way. In fact, the check that was done didn’t show an issue. I have zero explanation for how 20 other folks saw and verified the issue and this one volunteer did not. His replies were not at all helpful.

Nor is this one from Cloudflare where it appears that the full post was not even read. And zero answer about what was changed that caused the issue and what was changed that fixed it.

I would not run a site without it being on Cloudflare, nor would I maintain a site for clients without it. But the lack of disclosure about changes, or ways to report critically important issues, is beyond pitiful.

Do you realize how much time just dealing with this thread has taken - and not one shred of help in it!!!

[lloydw]

I did indeed read most of the thread, though I will admit I scrolled through most of the “me too” messages that provided no additional context. If there is something in there that I missed, I apologize.

And zero answer about what was changed that caused the issue and what was changed that fixed it.

Indeed. That is because in order to identify if there was a relevant change that affected you, I would need more information to narrow down what the problem was.

Based on the helpful curl outputs that @cscharff has provided, I am going to attempt to infer the answer to my first question, and an example answer for the second. It would be productive if you would be able to verify that these answers are correct, and if not, correct them. If a correction is necessary, please use explicit HTTP header names and values, for example content-security-policy-report-only vs CSP, and default-src https:; report-uri /csp-report vs directives.

Could you please specify what headers, and values, you are expecting to be set, and whether they are set by your origin server or by some setting you have in Cloudflare?

I would expect to see these headers:

cache-control: max-age=0, no-cache, no-store, must-revalidate
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-content-type-options: nosniff

which are set by my origin server, but they are no longer visible when requesting my website through Cloudflare. I have verified when directly requesting from my origin I can see these headers emitted.

If they are set by your origin server, and you are not seeing them, then we need to understand under what conditions these headers are set in order to know what, if anything, may have changed.

My origin only sends these response headers if the request includes the header accept-encoding with a value containing gzip.

If I can get responses of this form, it can help me be confident I’m looking in vaguely the right ballpark. If I get time in the next few days I can try to identify if there was a change on the Cloudflare side that fully explains the behaviours your saw, and then maybe even ensure that it does not happen again.

As I understand that the impact you felt cost you time and money, I would also like to take the opportunity to point out that Cloudflare’s paid plans include the ability to raise support tickets directly if needed: Contacting Cloudflare Support · Cloudflare Support docs.

[accounts16]

Not helpful to state that CF has direct support on paid plans. This issue is only on free plans. And instead of having multiple people open separate tickets, I instructed them to reply to this one, on this forum, as it is the only way for them to do that. Unlike opening a ticket, when replying to one that has already been created, there are zero fields to prompt for more info, including their domain. Next time I’ll tell them to share that.

I understand about the need to gather info. Do you realize that most folks on the free plan are non-techies? They would not know how to do checks or give details without explicit instructions on how. They likely don’t even know what half the stuff you or the volunteer mentioned is. I gave details about what I used to test - which are testers available to everyone.

Here is the header checker I used HTTP Headers Test by WebSitePulse

Here is what shows on https://blogaid.net, which is on the CF Pro plan
HTTP/1.1 200 OK Date: Mon, 14 Apr 2025 22:48:20 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive CF-Ray: 9306c00719984217-EWR CF-Cache-Status: HIT Age: 83420 Cache-Control: public, max-age=16070400 Expires: Sun, 13 Apr 2025 22:33:40 GMT Last-Modified: Sun, 13 Apr 2025 22:23:40 GMT Link: <https://blogaid.net/wp-json/>; rel="https://api.w.org/", <https://blogaid.net/wp-json/wp/v2/pages/21915>; rel="alternate"; title="JSON"; type="application/json" Strict-Transport-Security: max-age=31536000; includeSubDomains; preload Vary: Accept-Encoding,User-Agent alt-svc: h3=":443"; ma=86400 cf-apo-via: tcache cf-edge-cache: cache,platform=wordpress content-security-policy: block-all-mixed-content referrer-policy: no-referrer-when-downgrade X-Content-Type-Options: nosniff x-frame-options: SAMEORIGIN x-turbo-charged-by: LiteSpeed x-xss-protection: 1; mode=block Report-To: {"endpoints":[{"url":"https://a.nel.cloudflare.com/report/v4?s=Tlgem53gxUM5j%2FpRSyKPD96BwG 3%2BS%2FqiLHg%2FeZAxTwXsXLuW5dQhvwvNp3UHE7gyioEhkp41o%2F4kFxTseYFUDiTSC96hX3%2Bl7t%2BCi48H5MBB6UUJpA70nAzkN%2Bex"}] ,"group":"cf-nel","max_age":604800} NEL: {"success_fraction":0,"report_to":"cf-nel","max_age":604800} Server: cloudflare server-timing: cfL4;desc="?proto=TCP&rtt=3448&min_rtt=1542&rtt_var=4090&sent=4&recv=7&lost=0&retrans=0 &sent_bytes=2943&recv_bytes=620&delivery_rate=1453815&cwnd=252&unsent_bytes=0&cid=2a53fb43ce6bbb 4d&ts=70&x=0"

Here is what is on https://ecreatorshub.com which is on the free CF plan

HTTP/1.1 200 OK Date: Mon, 14 Apr 2025 22:48:02 GMT Content-Type: text/html Transfer-Encoding: chunked Connection: keep-alive Server: cloudflare Cache-Control: max-age=0, no-cache, no-store, must-revalidate Expires: Mon, 29 Oct 1923 20:30:00 GMT Last-Modified: Thu, 20 Feb 2025 16:24:13 GMT Vary: Accept-Encoding,User-Agent X-Xss-Protection: 1; mode=block Referrer-Policy: no-referrer-when-downgrade X-Frame-Options: SAMEORIGIN Content-Security-Policy: block-all-mixed-content Pragma: no-cache Alt-Svc: h3=":443"; ma=86400 X-Turbo-Charged-By: LiteSpeed Cf-Cache-Status: BYPASS CF-RAY: 9306bf968bd54264-EWR

Here is what is on another client’s site, https://www.farmersgirlkitchen.co.uk/ which is also on the free CF plan

HTTP/1.1 200 OK Date: Mon, 14 Apr 2025 22:55:39 GMT Content-Type: text/html; charset=UTF-8 Transfer-Encoding: chunked Connection: keep-alive Server: cloudflare X-Xss-Protection: 1; mode=block Referrer-Policy: no-referrer-when-downgrade Content-Security-Policy: block-all-mixed-content Vary: User-Agent,Accept-Encoding Last-Modified: Sun, 13 Apr 2025 15:39:34 GMT X-Frame-Options: SAMEORIGIN Cache-Control: max-age=0, no-cache, no-store, must-revalidate Pragma: no-cache Expires: Mon, 29 Oct 1923 20:30:00 GMT Cf-Cache-Status: BYPASS CF-RAY: 9306cabd6a977d14-EWR alt-svc: h3=":443"; ma=86400

Earlier today I rechecked ecreatorshub and it seemed to be working. But when I checked again this afternoon, it seems to be missing things again. I don’t know if the tester is caching or what. I inspected the URL using Chrome browser and saw the WP Fastest Cache directives. I just can’t see the headers.

The only explanation I have for why the volunteer saw all of the proper headers is that perhaps he checked after I purged CF during my tests, which does make everything appear for a while. Or, it’s an off/on type of issue, like what I’ve seen today.

If you have instructions for how to check things in a way that no browser/testing caching is involved, and doesn’t require access to things I can’t get to, like server logs, I’ll do it.

[francesco]

I confirm the issue doesn’t exist and Cloudflare works well on all my sites.

@accounts16 your answers suggest a lack of basic understanding of how the internet works. For example, why would you use a third-party online tool to check HTTP headers instead of simply inspecting them directly in your own browser?
Which probably means you’re doing something wrong on your side, not Cloudflare.

Anyway, nobody mentioned it, but if you want to enable HSTS and the no-sniff header, you can easily do so from the Cloudflare UI:

Sorry for intruding but I got this thread in a digest email and it got my attention

[lloydw]

Okay, while this doesn’t attempt to directly answer my questions, I’ve formatted and ordered the first two examples, and I can see the following header differences:

1. The free website example is not considered cacheable and is missing other headers related to that and the WordPress optimisation feature. That makes sense as this is a paid feature. This is visible from CF-Cache-Status: HIT vs CF-Cache-Status: BYPASS, and the absence of the Age, Link, cf-apo-via and cf-edge-cache response headers in the free website example that are present in the pro website example, as well as the presence of an additional Pragma: no-cache header. I think nothing there is being noted as an issue.
2. The NEL and Report-To headers are missing in the free website example. These are inserted by Cloudflare mainly for general observability of network issues across our network. We have an internal ticket tracking that these are currently missing for free websites as part of ongoing migration work.
3. The server-timing header is also missing from the free website. It is added by several different Cloudflare features, and I suspect none of these are enabled for this website.
4. strict-transport-security and x-content-type-options headers, which sound like they may be related to the original question, as strict-transport-security is the main header which the HSTS standard defines, and from x-content-type-options on the pro website having a value of nosniff, which was also mentioned in the initial post.

Based on this, I am going to assume at this time the question is about those last two headers. Again, please do correct me if this is not the case. @francesco has also pointed to the feature in the Cloudflare dashboard that enables these features to directly be set.

It does indeed look like a rollout of a new serving component, which has been happening over the past several months, and reached 100% of requests free websites last week after being at 50% of requests for several weeks, no longer supports this feature. It was rolled back early Friday evening UTC for unrelated reasons, and then back forward again yesterday once that issue was understood.

This feature not being supported was indeed a miss on Cloudflare’s side, and I’ll work on deploying a fix for this once I hit the reply button, and hopefully it will be out in the next couple of days.

[cscharff]

@francesco

I confirm the issue doesn’t exist and Cloudflare works well on all my sites

It’s entirely possible the issue did exist. I don’t doubt OP saw the issue, but the lack of provided logs of their testing and included ancillary details which were apparently out of scope made the ability to provide any guidance challenging.

[cscharff]

@lloydw

It does indeed look like a rollout of a new serving component, which has been happening over the past several months

For @accounts16 and their friends… it was indeed a change in Cloudflare’s part. Some folks commented Cloudflare made changes without notice.

You might not be aware, but Cloudflare is very public about how they view free accounts. In exchange for valuable services from Cloudflare they not only glean data about traffic and patterns they can use to protect their paying customers, your free domains are also a test bed for Cloudflare to tweak their features, routing and code fixes. The CEO has been very public about the value that ability to test and optimize provides.

[accounts16]

I did check them in my browser, and when I saw stuff missing, got verification from the testers. Then got verification from the host. Then got verification from the plugin dev.

The HSTS and NoSniff are set through those Cloudflare settings, which also state that they have not been changed in years.

Glad you can see all the headers. Me and my clients are getting knocked out of the Chrome HSTS list due to no HSTS header.

So, different folks in the world are seeing different things. Sounds like an issue with Cloudflare mirrored locations.

Thanks for being another bully who accuses but doesn’t help.

[accounts16]

I did not have a free plan site that worked to give you a comparison of what’s in the header and what’s not. Of course the paid plan one has more things, that is to be expected.

Yes, please focus on the missing HSTS for now, as that is knocking us out of the Chrome HSTS Preload list.

The roll in, out, and back in may also explain why it looked like it was working for some folks and not others.

Hopefully whatever gets fixed also stops the WPFC caching directives from getting knocked out.

[accounts16]

Yeah, not all of us are as perfect as you would like

[accounts16]

Not telling anyone what the changes are is the biggest issue. Every single week I have to update my webmasters for new settings that I can see. Too many of the ones that have been turned on by default are undesirable. Me, my clients, my webmasters and their clients, and our preferred host get tickets of things breaking our their visitors not being able to get to their sites. It costs time and money to figure out why for it to end up being a surprise Cloudflare change that nobody was told about. Or roll in and roll out that disappeared while we were troubleshooting.

Tell us about the changes!!!