Exciting things are coming - our community is moving to a new home!
Whilst we make this move, please note any posts/replies made between 21st February - 5th March 2026 will not be carried across. Learn more here.

Forum Discussion

ian_spa's avatar
ian_spa
Level 1.6: Donut
3 months ago

URL blocking and use of wildcards

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's avatar
    Lynda
    Google Community Manager
    3 months ago

    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!