Create and test Sophos Firewall Web Exceptions safely

A Web Exception is quick to create, but its impact can be much wider than expected. Depending on the selection, Sophos Firewall bypasses not only HTTPS decryption but also certificate validation, malware and content scanning, zero-day analysis, or complete web policy checks.

The safe order is therefore to identify the affected flow and the check that is actually causing the problem, then narrow the match, and only then enable the smallest necessary exception. A positive test alone isn’t enough. A similar destination that hasn’t been excluded must still undergo normal inspection in the negative test.

Web Exception in seven steps

1. Document the affected client, destination host, URL path, protocol, and time.
2. Check whether DPI mode or web proxy mode is in use and which firewall rule and web policy actually apply.
3. Decide whether only TLS decryption or a specific web protection check is causing the problem.
4. Under Web > Exceptions > Add an exception, define narrow URL, category, source, or destination criteria.
5. Under Skip the selected checks or actions, select only the smallest necessary option.
6. Turn on the exception and retest the same flow with a new browser or application process.
7. Run a negative test against a similar destination that hasn’t been excluded, and document the match, impact, owner, and review date.

⚠️ HTTPS decryption isn’t a harmless compatibility option. Dependent checks are also lost for matching traffic, and the firewall allows invalid server certificates in this case. Malware and content scanning automatically bypasses zero-day analysis as well. A broad exception must therefore not be the first troubleshooting step.

Choose a Web Exception or TLS exclusion

Both tools can prevent HTTPS traffic from being decrypted, but they don’t solve the same task.

An SSL/TLS inspection rule with Action: Don’t decrypt is suitable when only decryption must be excluded for clearly named destinations in DPI mode. A URL group in the Local TLS exclusion list is particularly efficient because the firewall compares Server Name Indication, or SNI, as text.

Create and safely use URL groups shows how to create such a domain list, assign it to a Don't decrypt rule, and test it against a negative destination.

A Web Exception is suitable when one of the following web protection checks must additionally or alternatively be bypassed:

• HTTPS decryption
• HTTPS certificate validation
• Malware and content scanning
• Zero-day protection
• Policy checks

In DPI mode, a Web Exception only applies if at least one web policy, Malware and content scanning, or ATP is active for the flow. In web proxy mode, the Web Exception belongs directly to the proxy-based web protection path.

Roll out TLS Inspection correctly covers the planned setup of DPI or web proxy, decryption rules, and CA deployment. Set up Web Protection with web policies explains the actual filtering logic.

Plan a narrow and traceable match

An exception shouldn’t begin with an arbitrary vendor domain. First record the specific request in the browser, Log Viewer, or application logs. Then decide whether the hostname, path, category, source IP, or destination IP is the most stable criterion.

AND between types, OR within a type

Sophos Firewall links different criterion types with AND. If URL patterns and Source IP addresses are specified, for example, both types must match.

Multiple values within the same type are evaluated with OR. Two URL patterns therefore mean that either pattern may be sufficient. Two Source IP addresses mean that either source may be sufficient.

This logic matters during troubleshooting. An exception can look correct and still fail to apply because an additional criterion type doesn’t match the real flow.

Anchor the regular expression safely

Regular expressions are allowed under URL pattern matches. A bare pattern such as vendor.example is unsuitable. It can also match the text at an unexpected position in the URL and exclude too many requests.

For the reserved example domain updates.vendor.example, a deliberately anchored host pattern can look like this:

^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/

The value is only an example. vendor.example is a reserved documentation domain and is replaced with the real destination host confirmed in the log or request. The optional prefix allows subdomains. If exactly one host must be excluded, no unnecessary subdomain wildcard is used.

Non-ASCII characters are specified as Punycode in the pattern. Every regex change requires an expected match and at least one deliberately similar non-match in the test.

Distinguish hostname and URL path

Exceptions for HTTPS decryption and HTTPS certificate validation can evaluate the hostname from the TLS context. A pattern that only targets a URL path, however, only works for HTTPS if the connection is already being decrypted.

This creates an important boundary: an exception can’t turn off decryption and then reliably use a part visible only in the encrypted HTTP path as its selection criterion. This case requires host-based scope or a different design.

Create the Web Exception

The example excludes a single pilot client from HTTPS decryption for a confirmed vendor host. It isn’t a universal exception rule.

1. Open Web > Exceptions.
2. Select Add an exception.
3. Enter a descriptive name, for example Vendor API no decrypt.
4. Turn on URL pattern matches.
5. Enter the tested, anchored pattern under Search/Add and select Add.
6. For the pilot, also turn on Source IP addresses and enter the specific client IP address.
7. Under Skip the selected checks or actions, select only HTTPS decryption.
8. Select Save.
9. In the list, turn on the switch for the new exception.
10. Recheck the name, Matching URLs, sources, and bypassed check.

The source IP address is set deliberately in the example. Without it, the exception would immediately apply to every client whose request matches the URL pattern. After a successful pilot, the scope can be expanded in a controlled manner to the sources that actually need it.

For a pure TLS exclusion across many destinations, a URL group in a Don't decrypt rule is usually more maintainable and efficient. Many FQDN host objects in the source or destination of an SSL/TLS inspection rule are inefficient because they can cause numerous DNS lookups for new TLS connections.

Understand the effect of the skip options

Before saving, it must be clear which protection is being lost.

HTTPS decryption

The firewall doesn’t decrypt matching HTTPS traffic. It therefore can’t perform checks that require decrypted content. Sophos also documents that traffic with an invalid server certificate is allowed for this match.

If only a certificate issue is causing the problem, this option is often too broad. First check whether HTTPS certificate validation is the more precise exception.

HTTPS certificate validation

The firewall bypasses server certificate validity checks. Configured decryption can continue. This exception is only suitable for a known destination with a consciously accepted certificate problem and requires a short review period.

An expired, incorrectly named, or untrusted certificate should be repaired on the destination system wherever possible. Deploying the correct inspection CA solves a different problem and is covered in Deploy the CA certificate for TLS Inspection.

Malware and content scanning

The firewall bypasses malware and content scanning for the match. This also automatically bypasses Zero-day protection. A single selection therefore removes two protection layers from the data path.

Before creating this exception, check the file type, scan limit, encryption, failure action, and the download that actually matches. Configure and test malware scanning provides the complete test flow.

Zero-day protection

Zero-day analysis is bypassed. No analysis reports are created for matching files, even if the classic malware scan reports a detection. This option is narrower than completely bypassing Malware and content scanning.

Policy checks

Web policy checks are bypassed for the matching request. Such an exception can render category, user, group, and other policy decisions ineffective. It should only be used for a clearly proven policy problem, not as a blanket solution for a blocked website.

Verify the effect with positive and negative tests

A successful page load only proves that something changed. It doesn’t yet prove that the exception is precise.

1. Record the time, pilot client, destination host, and expected result.
2. Close the existing browser or application session and create a new connection.
3. Repeat the affected request.
4. In Log Viewer, compare the source IP address, destination host, web policy, Firewall Rule ID, and action.
5. For a decryption exception, compare the server certificate visible to the client with its state before the change.
6. Open a similar destination that hasn’t been excluded.
7. Verify that this destination is still covered by the normal web policy, decryption rule, and scanning chain.
8. Briefly turn off the exception and reproduce the original error if this is safe within the maintenance window.
9. Turn the exception on again and reconfirm success.

If QUIC or HTTP/3 bypasses the expected TCP TLS path, the test can be misleading. Block QUIC and HTTP/3 correctly explains the boundary. Log Viewer, Policy Tester, and Packet Capture show which rule and policy actually match.

Narrow down errors systematically

Exception doesn’t apply

• The switch under Web > Exceptions isn’t on.
• An additional criterion type doesn’t match because of the AND logic.
• The regex isn’t anchored at the beginning or doesn’t represent the real hostname.
• The traffic isn’t decrypted for an HTTPS path exception, so the path isn’t visible.
• In DPI mode, neither a web policy, Malware and content scanning, nor ATP is active for the flow.
• A different firewall rule, web policy, or operating mode applies than expected.
• An existing browser or application session wasn’t recreated.

Exception applies too broadly

• The pattern contains an uncontrolled wildcard or only a bare root-domain string.
• Source IP addresses or another pilot scope are missing.
• Multiple URL patterns within the same type have a wider effect than expected because of OR.
• An entire web category was excluded instead of the specific host.
• Multiple skip options were selected even though only one check causes the problem.

Website works, but the protection impact is unclear

Don’t expand the exception further. First compare the browser certificate, web and SSL/TLS inspection logs, Firewall Rule ID, web policy, and a controlled download. Without this evidence, the exception is only a functional workaround, not yet an accepted security decision.

Review and rollback

Every production Web Exception has at least:

• technical justification and ticket
• application and firewall owner
• affected hosts, paths, sources, and user groups
• exact checks being bypassed
• date of the positive and negative tests
• review or expiry date
• documented previous state

For rollback, turn off the exception first rather than deleting it immediately. Then retest the original error, normal protection path, and unaffected destinations. Only remove the exception when no dependency remains.

Default and vendor exceptions shouldn’t be modified without control. A custom exception must make it clear why it exists and who will reassess it later.

Operational checklist

• DPI mode or web proxy mode identified.
• Actual matching firewall rule and web policy confirmed.
• Hostname and, where applicable, URL path captured from real traffic.
• Regex anchored at the beginning and tested against non-matches.
• AND between criterion types and OR within a type considered.
• Only the smallest necessary skip option selected.
• Automatic zero-day bypass for Malware and content scanning considered.
• Pilot source restricted.
• Positive and negative tests completed.
• Log Viewer, certificate, and protection impact checked together.
• Owner, ticket, review date, and rollback documented.

Frequently asked questions