Cloudflare Access - Wildcards to the right of sub-domains are not effective + need wildcards on the left of the application domain

I have this on my Cloudflare for Teams (Access) policy for a specific application:

It seems that no requests are getting an authentication request to login via GitHub (my only authentication method) and everything is just being let through, for example - to

Note that the domains staging-* (a few sub-domains) already exist, and are proxied through Cloudflare.

Why is this?

So it’s worth reviewing the application pathing documentation here:

The box at the bottom marked Important explains what you are encountering:


You cannot use wildcards to partially match subdomain and path names. Using asterisks in any way other than the ones outlined above will cause the wildcard to be invalidated . This means your application won’t be effective, and neither will be any rules you may try to enforce on it at a later time.

Entry Does NOT cover* ,
* ,

So you’d need to define an application for each subdomain you want to protect - or use * which would cover any/all subdomains

1 Like

So - this is inconvenient and doesn’t really work in real-life.

I don’t see why a simple wildcard has to have all these restrictions, as most naming conventions use some part of the domain as a top-level indicator e.g.


Given the fact that sub-sub-level domains have problems e.g. - the above seems to be the only way out. I cannot possibly sub-domain everything as * in a single rule.

Please look into expanding/fixing this.

1 Like

Thanks for the feedback - would you mind raising a suggestion in Product Requests - Cloudflare Community - others can vote on this and I’ll share it with the product team.

Also can you explain a bit more about the multi-level subdomain issues? What issues are you having using those?


The core problem is that wildcards are highly restricted, and they need to be usable anywhere in a string that expressed either a path or any level of sub-domain. We can’t auto-provision new developers with their own dev environment if we have to manually make new rules for each sub-domain inside Access/Teams, while also reconnecting other parts of our system which are sub-domain-sensitive to the new client URL’s. Our app isn’t just a single URL, it’s various components that rely on endpoints with a predictable schema, ideally under a single sub-domain. As an example - we can’t just restrict * without exceptions because these are public URL’s that must be left open: > our support manual > our production client UI

I also don’t see any way of declaring exceptions to an overall rule.

There should be no technical reason from the Cloudflare side that you cannot do * unless I’m missing something - but I understand it might not be ideal depending on your organisation and your own code / infrastructure.

Your feedback makes perfect sense - please do raise something that expresses this in the Product Requests category: Product Requests - Cloudflare Community others can then vote on it and it will help Product decide what to build next.

On your note about exceptions - there is also request in flight already on something similar that you might want to upvote and comment on: Access: Bypass rule by URL


sure - just posted here:

1 Like

Perfect - thankyou - I will be sure to flag these up internally to the Teams… ahem… Team :slight_smile:

1 Like

@simon to illustrate this - see this example. If we have 20 developers - we are not going to add 20 separate applications, if we can just do this (which doesn’t work):

Assuming there is a certificate on Cloudflare’s edge to cover the * this should work just fine.

1 Like

Unfortunately, on the specific rule, for the specific application above, I always get a Cloudflare Access “Forbidden” error when accessing something like this:

(person and subdomain are not real as I don’t want to make them public - but illustrate the point)

I also purchased the extra SSL certs for the wildcard under this subdomain, and added those under the section “Edge Certificates”