Skip to main content
I
ian_spa
New Member
December 11, 2025
Question

URL blocking and use of wildcards

  • December 11, 2025
  • 1 reply
  • 0 views

Morning all,

 

I'm a bit stuck with a policy configuration issue - I have a  managed device/user where access to websites is strictly controlled and so i have blocked access to URL's unless whitelisted, but its painful keep adding variations of these websites....I have played with the wild card option to allow full access to a URL but cannot get it to work for me. 

 

Has anyone successfully used this policy before in the way I have described? Any pointers/tips would be gratefully received. 

1 reply

Lynda
Lynda
Community Manager
December 19, 2025

Hi @ian_spa thanks for your post.

 

You are definitely not alone - wildcard syntax in ChromeOS policies can be a bit finicky if the formatting isn't exact.

 

When you are using the URLAllowlist to punch holes in a broad URLBlocklist, the behavior of the asterisk (*) depends entirely on where it is placed. Here are the three most common tips to get those wildcards working:

 

  1. The "Double Dot" Rule: If you want to allow a domain and all its subdomains (e.g., https://www.google.com/search?q=google.com, mail.https://www.google.com/search?q=google.com, and docs.https://www.google.com/search?q=google.com), don't just use "https://www.google.com/search?q=google.com". Use "https://*.www.google.com/search?q=google.com". This standard pattern that covers the root domain and any sub-levels.
  2. Path Constraints: Chrome's policy engine is best at filtering by host. If you try to use complex wildcards in the middle of a URL path (like "website.com/*/login"), it often fails. It is usually more effective to allow the host entirely.
  3. Protocol Matters: If you don't specify a protocol, Chrome assumes you mean both HTTP and HTTPS. However, if the site uses a non-standard port, you must include it (e.g., "[*.]https://www.google.com/search?q=example.com:8080").

One common trap: Ensure you aren't accidentally blocking a "hidden" dependency. Sometimes a site like "mytools.com" won't load because it pulls its scripts or fonts from a different domain (like "gstatic.com" or "aws.amazon.com"). If those secondary domains are blocked, the main site will break.

 

If you have a specific URL pattern that's failing, feel free to share a sanitized version of it here and we can help troubleshoot the exact string!

    Terms & ConditionsCookie settingsAccessibility statement