Specifying Per-Site Policy with Chromium’s URL Filter Format

Chromium-based browsers like Microsoft Edge make very limited use of Windows Security Zones. Instead, most permissions and features that offer administrators per-site configuration via policy rely on lists of rules in the URL Filter Format.

Filters are expressed in a syntax (Chrome Doc, Edge Doc) that is similar to other types of globbing rules, but different enough to cause confusion. For instance, consider a URLBlocklist rule expressed as follows:

These filters don’t work as expected. The HTTPS rule should not include a trailing * in the path component (it won’t match anything), while the data: rule requires a trailing * to function.

The syntax has a few other oddities as well:

• You do not use a * to represent a part of a hostname: the * character is only used by itself to mean “ALL hosts”. A rule of *xample.com is invalid and does not match example.com.
• The right way to express “Match example.com and its subdomains” is just example.com. If you want to match only the hostname example.com, and none of its subdomains, use .example.com (note the leading dot).
• You may specify a path prefix (example.com/foo) but you must not include a wildcard * anywhere in the path
• You may specify wildcards in a querystring (example.com?bar=*). You may omit the preceding path component to have that querystring checked on all pages, or include a path to only check the querystring on pages within the path.
• A rule of blob:* doesn’t seem to match blob URLs, while a rule of data:* does seem to match all data URLs.

Unfortunately, there’s not a great debugger for figuring out the proper syntax. You can use the chrome://policy page to see whether Chrome finds any glaring error in the policy:

…but short of testing your policy there’s not a great way to verify it does what you hope.

Q: The problem of special-URLs

There are a variety of special URLs (particularly blob and data) that do not directly express a hostname– instead, the URL exists within a security context that is not included in the URL itself. This can cause problems for Policies if the code implementing the policy does not check the URL of the security context and looks only at the blob/data URL directly. A system administrator might set a policy for downloads from https://example.com/download, but if download page on that site uses a script-generated file download (e.g. a blob), the policy check might overlook the rule for example.com because it checks just the blob: URL.

An example bug can be found here.

Q: Can I block everything by adding * to the URLBlocklist?

You can add a simple * rule to the URL Blocklist, but then you must add to the URLAllowlist overriding rules to cover every URL that you need to allow to load in the browser. Beyond the https:// sites you expect, this includes, for example, about:, data:, edge:, and other URLs that you probably haven’t thought about.

Q: Can filters match on a site’s IP?

The Permissions system’s “Site Lists” feature does not support specifying an IP-range for allow and block lists. Wildcards are not supported either.

It does support specification of individual IP literals (e.g. http://127.0.0.1/), but such rules are only respected if the user navigates to the site using said literal IP address. If a non-address hostname is used (http://localhost), the IP Literal rule will not be respected even though the resolved IP of the host matches the filter-listed IP.

Aside: Wildcard support for IP-literals might be nice, so that an admin could specify e.g. http://192.168.* to exempt their private network. Unfortunately, Chromium couldn’t implement a syntax that is quite that simple — if it did, an attacker could just name their evil server https://192.168.evil.com and exploit their enhanced permissions.

Q: Can filters match just dotless hostnames?

Not today, no. You must individually list each desired hostname, e.g. (https://payroll, https://stock, https://who, etc).

Chromium’s URL Filter Format is convenient if your intranet is structured under one private domain (e.g. *.intranet.example.com) but is much less convenient if your Intranet uses dotless hostnames (http://example) or many disjoint private domains.

The ability to match only hostnames not containing dots would be convenient to accommodate the old IE behavior whereby Windows would map dotless hostnames to the Local Intranet Zone by default. (To my surprise, there’s been no significant demand for this capability in the first year of Edge’s existence, so perhaps corporate intranets are no longer using dotless hostnames very much?)

References

• Edge Docs: Filter format for URL list-based policies
• Chromium Docs: URL list filter format
• Chrome Docs
• URL Filter Pattern is contrasted with Content Settings Patterns used by the site permissions system. (tl;dr, Content Settings Patterns uses a bracket-wrapped wildcard [*.] as its wildcard sequence)