Forum Discussion
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
- LyndaGoogle Community Manager3 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:
- 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.
- 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.
- 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!
Related Content
- 25 days ago
- 2 years ago
- 2 years ago
- 3 years ago