ACTION REQUIRED: URL Normalization has NOT been enabled on your Cloudflare zone(s)

Just got this email:

Dear customer,

This email is to inform you of how the recently launched URL Normalization functionality impacts your zone(s) specifically. Please ensure you read and fully understand what this change means for your zone(s): example.com

As your zone(s) contain firewall rules using fields with values that would be changed with normalization applied we have not enabled URL Normalization automatically . This is to prevent any change in behavior of your existing firewall rules.

We strongly recommend enabling ‘Normalize Incoming URLs’ to strengthen your zone(s) security posture. Not doing so will leave your zone at greater risk of a successful attack. The risk of not having URL Normalization enabled is that malicious actors could craft the URL in a way that the rules aren’t accounting for (e.g. using percent-encoding).

Before enabling URL Normalization, we recommend you review the affected firewall rules on the zone(s) and take one of the following approaches:

  1. Edit these Firewall Rules to remove the parts which will no longer trigger once normalized, e.g. any rules that are looking for ‘//’ or ‘…/’ in URL paths.
  2. If you wish to retain these firewall rules looking for such patterns, perhaps because you are trying to identify visitors using non-normalized URI paths, then they should be updated to use the original, non-normalized fields.

Once the affected firewall rules have been updated URL Normalization should be enabled.

Conclusion
URL Normalization is a new security improvement we have rolled out to the vast majority of Cloudflare zones automatically. We have not enabled URL Normalization on your zone(s) as we detected firewall rules that could be impacted. We strongly recommend that these firewall rules are updated and URL Normalization is enabled to ensure a stronger security posture on the zone(s).

Detailed instructions on what to do prior to enabling URL Normalization can be found on the KB article.

If you have further questions, please review our documentation or create a post on Cloudflare Community.

I think I have found the rule in question (a //login.php path, however is their a way to double check I have removed all offending rules before enabling Normalization, so as not to break anything?

The KB article being linked to (which I hoped might have such info) returns a 404

1 Like

Yea, so much for referring to the Knowledgebase when it’s a 404 (-_- ||)

BTW… quick question, is ending with a ’ / ’ not normalized too? Like /wp-admin/

1 Like

Got also the Mail. Have some FW Rules, and need to know, how exactly they have to be adapted

2 Likes

we are asking ourselves the same question… its unclear as to what is even going on.

All of the domains in the email I got as being ones that were NOT ENABLED I checked and they actually were enabled. Also none of them had firewall rules with // or ./.

Seems like the emails were sent in error.

How do you even see if it is enabled or not?

I def have // and if the …/ means a dir with an index file in, then I also have those.

Rules then “Settings” on the right side.

The Firewall Tab do you mean?

I dont see anything relating to Normalization on that Settings page

Do you mean a different location?

No it’s definitely under rules.

imho i think what they want is the “normalize urls to origin” meaning that they would normalize the request they sent to your server, while turning that on some of our page rules pose a “security risk” in which unnormalized queries can still hit the server.
is this just a way to say they are running url decode on the proxy?

in the end i bet we will receive another email :smiley:

headsup: the kb just went live… KB article i bet someone forgot to clear their cache ealier… not that that has happened ever to me cough

just looking at the kb KB article i think wordpress rules is not what they meant. they are talking about …/ or // in the url
Edit these Firewall Rules to remove the parts which will no longer trigger once normalized, for example, any rules that look for // or …/ in URL paths. Administrators previously created these rules to perform a limited sort of URL Normalization, and these rules can now be safely disabled and then deleted.

Sooo i get it now… basically:

therefore:
watch your firewall rules to actually match after normalization.

1 Like

This is not in my userpanel

This is what I see:

Firewall or Page Rules?

The KB article is extremely thin on the ground with actual examples of incorrect vs correct entries

You 3rd post above is much more helpful but is it Firewall or Page Rules or BOTH?

Also does it want locations like *example.com/home/ to instead be *example.com/home ?

in the end i just activated both url normalization settings (to cloudflare and from cloudflare to my server) for me it worked as expexted.
What i can say is that my firewall rules look like this:
(http.request.uri.path eq “/wp-admin/admin-ajax.php”)
whereas my page rules are absolute! like https://www.XXYYXY.de/wp-admin/admin-ajax.php?action=rest-nonce

i do not expect that anybody here was actually at risk, but now that we got all the info here, maybe an intern can actually write a blog post about it :wink:

enjoy guys

forgot to source this sorry:

How?
I dont have a Tab that simply says “Rules” instead it says “Page Rules” and contains ONLY Page Rule settings as per this:

I have URLs in my Firewall (not Page Rule) that are just like they describe, with double // and with them like example.com/dir/ ← with the slash at the end.

So I get why I have the email, but I dont get how to turn it on or how to check if I will not have issues (CF obvs have some kind of script that checks your Rule for problems, is there a way to use that prior to implementation?)

Iam Sorry but that is not what it looks like for me:


despite the german ofc

I recommend everyone check out the Wikipedia page on URI Normalization here: URI normalization - Wikipedia

What CF is referring to specifically are these two cases:

  1. Removing duplicate slashes
  2. Removing dot-segments.

If you use “normal” URLs with https:// (two slashes) and / in the URL as a path component you will be fine.

You can find these options under “Rules → Settings (all the way to the right)” then turning both on.