Cloudflare Access wildcard logic change

bikegremlin

In case you are using Cloudflare Zero Trust with wildcards, and have missed this note from the company:

You are receiving this email because your account has an Access Application with a wildcard definition that will begin to cover more URL combinations. We are updating our wildcard behavior in Cloudflare Access for wildcards at the end of a path not following a slash character (e.g. example.com/text*). If no action is taken before April 20th, 2023, an Access login screen will be presented for additional path combinations.

Current Access Application behavior
example.com/alpha* will cover example.com/alpha and example.com/alpha/one but not example.com/alphabet.

Change impact
After April 20th, 2023 at 20:00 UTC, all three path combinations will be covered by Access. If you would like to exempt specific paths from Access, a Bypass policy can be configured.

How to identify impacted Access Applications
To identify which Access Applications will be impacted by this change, please open the Zero Trust Dashboard, navigate to Access→Applications and search for the * character. This will highlight any applications that may require modification.

I consider this to be the logical way the wildcard should work - as it should have been from the start.

I've updated my Cloudflare Zero Trust article - as this wildcard function was one of my complaints.

Erisa

Relevant blog entry for further reference: https://blog.cloudflare.com/access-wildcard-and-multi-hostname/

Fritz

May I know why you choose to use ZeroTrust instead of masking your login page with Wordpress security plugin?
Like site.tld/mysecretaccess for backend.

Deny access to wp-login and wp-admin with htaccess,
Or even whitelist access to WP backend only to your own IP.

bikegremlin

@Fritz said:
May I know why you choose to use ZeroTrust instead of masking your login page with Wordpress security plugin?
Like site.tld/mysecretaccess for backend.

Deny access to wp-login and wp-admin with htaccess,
Or even whitelist access to WP backend only to your own IP.

That's a good and reasonable question. The short answer is: layers.

This protection acts before the visitor even reaches the hosting server (so it wont even "bother" it if it's a bot).

For more details on my security approach & philosophy, I wrote several articles:

How to secure a WordPress website

Domain and website security