Web content filtering on iOS devices

Web Content Filtering allows administrators to regulate internet access on iOS devices by blocklisting or allowlisting specific URLs. This ensures secure browsing, protects devices from malicious sites, and maintains corporate compliance.

1. Configuration Workflow

This feature is supported only on Supervised iOS devices running iOS 7.0+.

To set up Web Content Filtering:

1. Log in to the Hexnode UEM portal.
2. Navigate to Policies > New Policy > Create a fully custom policy > iOS > Security > Web Content Filtering and click Configure.
3. Choose the Filter Type: Blocklist or Allowlist.

Filter Type 1: Blocklist

Use this to deny access to specific, known-bad, or non-work-related websites.

Filter Type 2: Allowlist

Use this for high-security environments where only specific approved websites should be accessible.

2. Critical Technical Behaviors

Once a Web Content Filtering policy is active, the following system changes occur on the iOS device:

• Browser vs. App Access: Usually, when a URL is blocklisted in web filtering, it blocks access only in the browsers. It is often still possible to access the corresponding app. In such cases, Hexnode allows the blocklisting/allowlisting of apps to strictly control access.
• Private Browsing Disabled: Users cannot open private tabs in Safari.
• History Deletion Disabled: Users are prevented from clearing their browsing history or website data.
• Redirection: If a blocklisted site redirects to an unlisted URL, the redirected page may be accessible unless also explicitly blocked.
• URL Variations: Different versions of a site (e.g., mobile vs. desktop) are treated as separate URLs and must be added individually.

3. Policy Association & Conflicts

• Deployment: Associate the policy with Devices, Groups, Users, or Domains/OUs via the Policy Targets tab.
• Conflict Handling: If both a Blocklist and Allowlist policy are applied to the same device:
  • URLs common to both policies will be blocked.
  • Only URLs unique to the Allowlist remain accessible.
  • Example: If URL (A) is allowlisted but also exists in a blocklist policy, URL (A) will be restricted.

4. What Happens at the Device End?

Once the Web Content Filtering policy is successfully associated with a supervised iOS device, the following behaviors are immediately enforced:

• User-End Prompts (Blocklist): If a user tries to access a blocklisted page (e.g., https://youtube.com), the device displays a prompt stating that the given page is restricted.
• User-End Prompts (Allowlist): If a user tries to access any webpage other than the ones explicitly allowlisted, the device prompts that the page is restricted, and access is denied.

5. Troubleshooting & FAQs

Frequently Asked Questions (FAQs)

1. Does Web Content Filtering work on non-supervised iOS devices?

   No. Web Content Filtering is an advanced restriction that Apple only permits on Supervised iOS devices.

2. Does this work on third-party browsers like Chrome?

   Apple’s native Web Content Filtering primarily targets the Safari engine. While many third-party browsers on iOS use the same engine, behavior may vary; for absolute control, restrict the device to Safari only.

3. Can I block URLs without a protocol?

   No. All URLs must include a valid protocol (http:// or https://) to be recognized by the filtering engine.

Troubleshooting

• Content Still Accessible via App: Blocking a URL (e.g., youtube.com) restricts the browser but does not automatically block the native YouTube app. Use App Management to block/allow specific applications.
• Policy Not Applying: Verify that the device is Supervised. Web Content Filtering payloads are ignored by unsupervised devices.
• Redirect Loops: If an allowlisted site fails to load, check if it relies on resources from a different (unlisted) domain. All supporting domains must be allowlisted.