Restricting Web Access on macOS in Chrome and Safari

On macOS, Safari and Chrome don't share a management mechanism. Each is controlled by a different payload inside the configuration profile, so restricting web access means configuring both — there's no single setting that covers the two.

This guide walks through each one, and through the trap that catches most people in Safari.

Before you start

• The Mac is enrolled in Applivery through Apple MDM, Automated Device Enrollment, or manual enrollment. Neither payload requires supervision.

• Both payloads can be imported as a custom configuration: go to Policies, select your macOS Policy, then + Add configuration → + Import, and either paste the XML or upload it with Load XML.

• For Safari, there's a better route — Applivery exposes the payload as a native configuration under + Add configuration → Parental Controls: Content Filter.

• You can combine both payloads in the same .mobileconfig under one PayloadContent, or import them as independent configurations in the same Policy.

Google Chrome

Chrome on macOS is managed through managed preferences injected into the com.google.Chrome domain, using its native URLBlocklist and URLAllowlist policies.

Go to Policies 1, select your macOS Policy, then + Add configuration → + Import 2, and paste or upload the XML.

Blocking specific domains

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>PayloadContent</key>
  <array>
    <dict>
      <key>PayloadType</key>
      <string>com.google.Chrome</string>
      <key>PayloadUUID</key>
      <string>7D9A8B87-7A4F-4B9E-9C75-111111111111</string>
      <key>PayloadDisplayName</key>
      <string>Google Chrome - URL Blocklist</string>
      <key>PayloadIdentifier</key>
      <string>com.google.Chrome.7D9A8B87-7A4F-4B9E-9C75-111111111111</string>
      <key>PayloadVersion</key>
      <integer>1</integer>
      <key>URLBlocklist</key>
      <array>
        <string>website1.com</string>
        <string>website2.com</string>
      </array>
    </dict>
  </array>
  <key>PayloadDisplayName</key>
  <string>Chrome URL Policy macOS</string>
  <key>PayloadIdentifier</key>
  <string>com.applivery.profile.f537cccc-6b42-4a4d-a432-9ef86ae7366a</string>
  <key>PayloadType</key>
  <string>Configuration</string>
  <key>PayloadUUID</key>
  <string>8c99db2f-eb79-4b1a-9099-827422b47588</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
</dict>
</plist>

Allowing only a list of sites

Block every host with a single asterisk, then list the exceptions:

<key>URLBlocklist</key>
<array>
  <string>*</string>
</array>
<key>URLAllowlist</key>
<array>
  <string>mail.google.com</string>
  <string>applivery.com</string>
</array>

Filter format

Entries follow the pattern [scheme://][.]host[:port][/path][@query].

Two limits worth knowing:

• The asterisk isn't a general wildcard. *.website1.com doesn't work as a way to cover subdomains — a bare website1.com already does that. It isn't accepted at the end of a path either, so https://example.com/* is not a valid entry.

• You can list up to 1,000 entries.

Checking it applied

On the Mac, open chrome://policy and confirm that URLBlocklist or URLAllowlist appear with Source: Platform and the value you expect. If they're not there, the profile hasn't landed; if they're there but browsing still works, the browser hasn't been restarted.

Once it's working, visiting a listed site shows Chrome's blocked-page message.

Safari

Safari on macOS doesn't use the WebContentFilter payload from iOS and iPadOS — that one is supervised-only and iOS-specific. On macOS, the equivalent is the Parental Controls payload, com.apple.familycontrols.contentfilter.

You can import it as custom XML, but the native form is the better route. Both are covered below.

Using the native form

Applivery exposes this payload as a native configuration, with the fields translated and validated in the Dashboard.

1

Open your macOS Policy

Go to Policies 3, and select the macOS Policy you want to modify.

2

Add the configuration

From the left side menu, click + Add configuration, search for parent, select Parental Controls: Content Filter 4, and click + Add.

The master switches

Restrict Web must be ON for any filtering to happen at all. With it off, nothing else in the configuration has any effect. The same applies to Use Content Filter, which turns on Apple's automatic content filtering.

Two modes, mutually exclusive

The form follows the same logic as the payload: only one mode applies at a time.

Selective blocking — block specific sites, everything else stays reachable:

• Filter Blacklist: the sites to block, one per entry with + Add element.

• Filter Whitelist: exceptions within that blocking. Useful mainly when Use Content Filter is on, and the automatic adult-content filter is catching a site it shouldn't.

• Whitelist Enabled must stay OFF. Turning it on switches you to the other mode and the blacklist stops applying.

Allow only listed sites — block everything except a list:

• Whitelist Enabled: ON.

• Site Whitelist: the only field that has any effect in this mode, and required once Whitelist Enabled is on.

• Filter Blacklist is ignored while this mode is active. You don't need to empty it.

Using custom XML

If you'd rather import the payload directly, this blocks specific sites:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
  <key>PayloadContent</key>
  <array>
    <dict>
      <key>PayloadType</key>
      <string>com.apple.familycontrols.contentfilter</string>
      <key>PayloadUUID</key>
      <string>A2B3C4D5-6E7F-4A1B-9C2D-222222222222</string>
      <key>PayloadDisplayName</key>
      <string>Safari - Content Filter</string>
      <key>PayloadIdentifier</key>
      <string>com.applivery.safari.A2B3C4D5-6E7F-4A1B-9C2D-222222222222</string>
      <key>PayloadVersion</key>
      <integer>1</integer>
      <key>restrictWeb</key>
      <true/>
      <key>useContentFilter</key>
      <true/>
      <key>filterBlacklist</key>
      <array>
        <string>https://www.website1.com</string>
        <string>https://www.website2.com</string>
        <string>https://website3.com</string>
      </array>
    </dict>
  </array>
  <key>PayloadDisplayName</key>
  <string>Safari URL Policy macOS</string>
  <key>PayloadIdentifier</key>
  <string>com.applivery.profile.b6d1e2f3-4a5b-4c6d-8e9f-0a1b2c3d4e5f</string>
  <key>PayloadType</key>
  <string>Configuration</string>
  <key>PayloadUUID</key>
  <string>b6d1e2f3-4a5b-4c6d-8e9f-0a1b2c3d4e5f</string>
  <key>PayloadVersion</key>
  <integer>1</integer>
</dict>
</plist>

And this allows only the listed sites:

<key>restrictWeb</key>
<true/>
<key>whitelistEnabled</key>
<true/>
<key>siteWhitelist</key>
<array>
  <string>https://mail.google.com</string>
  <string>https://applivery.com</string>
</array>

URL format in Safari

• URLs must start with http:// or https://. If a site answers on both, add an entry for each.

• Matching is by string root. Blocking https://www.website1.com also blocks www.website1.com/example and any path underneath it — but it does not automatically cover other subdomains such as example.website1.com. Add those as separate entries if you need them.

• Redirects aren't followed. If a blocked or allowed URL redirects elsewhere, the destination has to be on the list too.

• The filter also disables clearing Safari history and browsing data, and turns off private browsing.

Blocking the website isn't blocking the tool

Blocking a domain in Chrome or Safari only stops access through the browser. Plenty of tools ship a native desktop app that talks to its servers directly, never touching a browser, and is therefore untouched by URLBlocklist or filterBlacklist.

If the goal is to stop people using a service rather than just visiting its website, pair this configuration with app control — see Block & Allow Apps.

Payload summary

Before you roll it out

Deploy to one Mac first and confirm two things: that the policy arrived, using chrome://policy for Chrome, and that the browser has been restarted. Most reports of "the block isn't working" come down to one of those two, not to the payload itself.