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.

This guide applies to SFOS 22.0. WebAdmin labels deliberately remain in English so that they can be found directly in the interface.

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.

Check product prerequisites before choosing an exception

For some managed products, port and domain allowances are prerequisites for the relevant function. Before choosing a firewall rule, TLS exclusion, or Web Exception, establish the product, function, version, and actual connection path with the product owner. Record required destinations, ports, protocols, directions, and explicitly required inspection exclusions in the change ticket rather than granting blanket access to all Sophos products.

• Wireless: The Wireless preflight separates the management network, DNS, time service, and regional destination requirements from later wireless configuration.
• ZTNA: First identify the local or cloud deployment in the ZTNA gateway guide; their connection directions and inspection requirements are not interchangeable.
• Switch registration: Switch onboarding covers DNS, registration destinations, and checks of the proxy/TLS path.
• Endpoint, XDR, and MDR: The network and proxy requirements distinguish platforms, licensed functions, and installation-specific destinations. A domain allowlist is not a blanket no-decrypt list.
• NDR and integration appliances: Appliance planning covers outbound port and domain requirements; the operations runbook helps check the NDR and log collector functions actually hosted on the appliance separately.

The internal guide is a starting point; the product owner must confirm the authoritative requirements for the specific deployment before the change. Network reachability and inspection bypass remain separate decisions. If a verified requirement set is missing or sources disagree, don’t widen the exception speculatively: preserve evidence and resolve the issue with the product and firewall owners. The pilot, positive/negative tests, review, and rollback in this guide still apply afterwards.

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.

The SSL/TLS exclusion list uses plaintext domain names and includes their subdomains, rather than using regular expressions. SSL/TLS exclusions can exempt certificate and protocol enforcement as well as decryption. They are therefore not equivalent to a Web Exception for HTTPS certificate validation alone. Confirmed domains can be added to the Local TLS exclusion list in the Control Center or Log Viewer; alternatively, edit the URL group under Web > URL groups or the SSL/TLS inspection rule. Web categories can also be criteria in an SSL/TLS inspection rule.

The traffic covered also differs: in DPI mode, Web Exceptions apply to SSL/TLS connections on any port; in web proxy mode, they apply to SSL/TLS on port 443. SSL/TLS exclusion rules only apply in DPI mode, but are also port-independent. In addition to URL groups, they can use zones, networks, IP addresses, services, users, and groups as criteria. Web Exceptions provide URL patterns, web categories, and source and destination IP addresses or ranges.

An active Web Exception can override the selected protection checks for matching web flows; this is not a promise that every system-level block can be lifted. Its scope therefore can’t be protected by placing a web policy rule later in the order. The exception’s own criteria are decisive; still check firewall, web, and SSL/TLS rule order separately because they determine which protection path processes the flow in the first place.

Documented boundary and unresolved conflict: Sophos describes exceptions generally as independent of policies and rules. However, the category guidance for SFOS 22.0 and 23.0 explicitly identifies highly objectionable criminal activity as always blocked: no policy or exception may allow these pages, and domain names are intentionally hidden in logs and reports. These differing statements do not establish a working bypass. The safe approach remains not to circumvent this block and, if necessary, clarify the conflict with Sophos Support. Use only harmless, approved destinations for tests, never prohibited content.

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.

Check dots, host boundaries, and unwanted path matches

In a regex, an unescaped dot represents any character. Dots in a fixed hostname are therefore written as \.. The ^ anchors the match at the beginning; the trailing / separates the host from similarly prefixed names such as updates.vendor.example.attacker.example. Sophos Firewall accepts / and \/. For exactly one host, the narrower pattern is:

^updates\.vendor\.example/

The examples refer to the host/URL representation to which these Sophos patterns are applied, without a leading https://. A test tool must use the same representation. For different ports or another representation, don’t speculatively add .*; establish the value actually evaluated and the protection path instead. The HTTPS limitation in the following section still applies.

The following expectations apply to the exact-host pattern. With the existing optional-subdomain pattern, cdn.updates.vendor.example/file is also an intended match; the other negative cases remain non-matches.

The last two cases are particularly important: matching may cover the entire URL, including its path and query. An unanchored domain string can therefore trigger the exception on another host. This test checks matching only; whether protection checks are actually bypassed is verified later with a new request and logs.

Test long non-matches locally

Many unanchored patterns can require additional searching, especially when HTTPS decryption makes the full URL text available. This does not establish a universal step count or an invariably constant, linear, or exponential runtime for every pattern. Anchoring does not replace reviewing complex quantifiers either. Don’t use a blanket .* wildcard for hostnames.

A 1000-character test supplements the short cases. On a local administrator workstation with Python 3, this example creates entirely fictitious URL text with a long path and the target domain only in the query. It tests both patterns shown here without contacting a firewall:

import re
from time import perf_counter

prefix = "other.example/"
suffix = "?next=updates.vendor.example/file"
value = prefix + "a" * (1000 - len(prefix) - len(suffix)) + suffix
assert len(value) == 1000
patterns = [
    r"^updates\.vendor\.example/",
    r"^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/",
]
for pattern in patterns:
    regex = re.compile(pattern)
    start = perf_counter()
    for _ in range(100):
        assert regex.search(value) is None
    print(pattern, "Nicht-Treffer, Sekunden:", perf_counter() - start)

Two non-matches are expected. Further synthetic cases should cover long, almost-matching hostnames and long paths; compare before/after patterns using the same inputs. For suspicious complex patterns, use a local tool with a time limit and stop any hanging test. Python timings and step counters from other regex engines are not SFOS measurements or performance promises. Don’t copy production URLs, tokens, usernames, or customer data into external regex websites; fictitious data is sufficient for these tests.

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. With unencrypted HTTP, the URL path is visible without TLS decryption.

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, enter the specific client IP address, and select Add.
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.

Prepare a new host exception in Config Studio

Config Studio can create a new Web Exception from a domain name without first importing an existing exception. This is a separate workflow; Bad regex and Apply Fix are used to repair existing entries as described further below. The new exception is initially prepared locally and is only applied to the firewall through the TAR import.

First store a complete firewall backup and an unchanged selective export of WebFilterException from the same firewall in a protected location. Export WebFilterException and check it with Config Studio explains the export of Entities.xml, file handling, and the subsequent download. Record an unused name, the confirmed destination host, the required skip option, and the intended client scope in the change ticket. An existing name is not a safe way to add another entry: the import updates matching existing exceptions. Changing a name creates a new entry instead and does not remove the old one.

1. Open Config Studio using the access link below, select Configuration editor, and go to Rules > Web exceptions.
2. Select Add and enter the new, unique name, such as Vendor API exact host no decrypt.
3. Under Skip these checks, enable only the option needed for the task. For the decryption example, this is Skip HTTPS decryption. The other options are Skip policy check, Skip cert validation, Skip malware scan, and Skip zero-day protection. The protection consequences described above also apply when creating an entry in the editor; do not select several options as a precaution.
4. Under Match by URL/Domain, select the scope: Exact host only for precisely the confirmed host, or Domain + all subdomains if all its subdomains are explicitly required and approved. For updates.vendor.example, the example keeps Exact host only selected; cdn.updates.vendor.example must not be included.
5. Enter the confirmed domain name in the text field without a URL path, for example updates.vendor.example. Replace this documentation value with the real destination host. The generated regex and preview appear automatically; check both against the planned scope and the positive/negative cases described above.
6. Select Add to URL Regex list. The pattern must then appear under URL Regex Patterns. A visible preview value alone is not yet an entry added to the list.
7. Optionally, under URL Regex Patterns, use + Add URL regex to add your own previously tested pattern directly. This is not needed for domain-based creation; additional patterns broaden the possible match because of OR.
8. Finally, select Add at the bottom of the side form. Only this step creates the new exception in the editor.

Before downloading, use Preview to compare the import XML with the saved baseline and the change ticket. Only the approved new exception may be added; existing names, criteria, activation states, and skip options must not be changed unintentionally. The client scope must also be correct: Exact host only restricts the destination, not the sources. If the generated configuration does not demonstrably include a required pilot source, do not import it; instead, use the WebAdmin workflow above with Source IP addresses. Do not add unverified extra fields to the XML.

Then select Download > Download TAR and store the archive in a protected location. Import, verify the effect, and roll back covers import messages, before/after comparison under Web > Exceptions, activation checks, and new connections with positive/negative tests. The XML preview or a successful import does not replace this protection-effect test. If the result is unexpected, disable the new entry in a controlled manner and recheck the normal protection path. Reimporting the original selective export does not automatically remove the newly created exception; remove it explicitly only after dependencies have been clarified. Leave existing exceptions untouched.

Exclude a category rather than a single domain

If confidential financial data must not be decrypted, the Financial services category may be the appropriate criterion. A category exception covers more destinations than a single host, however; its classification must fit the intended scope.

1. Under Web > Exceptions > Add an exception, enter a name such as Financial services no decrypt.
2. Turn on Web site categories, select Add new item, and choose Financial services.
3. Confirm with Apply selected items. For the pilot, also set Source IP addresses using the client IP address and Add.
4. Select only HTTPS decryption, select Save, and turn on the switch in the list.
5. Test an approved financial service and a harmless destination outside the category using new connections. Both the pilot source and category must match because of AND.

Matching HTTPS connections lose decryption and dependent content checks; the certificate consequence described above also applies. This is not blanket permission for the category or a statement that every other protection function is disabled.

Malware exception for a confirmed download host

A provider assessed as low-risk is not, by itself, a reason to disable scanning. If a justified exception is necessary, use the procedure above with a separate name such as Vendor download scan exception, the confirmed host pattern, and the pilot source. Select Malware and content scanning instead of HTTPS decryption. Zero-day protection is selected automatically; older exceptions that bypass malware scanning also bypass zero-day analysis. Then select Save and turn on the switch. Matching downloads lose malware/content scanning and zero-day analysis, including its analysis reports. Do not additionally deselect the other checks. Verify the intended protection path with a harmless, controlled download from the approved host and a comparison destination that is not excluded; a successful download alone is insufficient.

Enter other criteria and manage existing exceptions

Populate Destination IP addresses with the confirmed website IP address and select Add, not with the client IP address. For permitted combinations of destination criteria with URL or category criteria, all selected types must match. URL patterns use ASCII characters; internationalised domain names use Punycode. Matching URLs in the default Apple Update exception can serve as a syntax example, not an unverified allowlist template.

TLS exclusion: conflicting scope guidance. The SFOS 22.0 and 23.0 Add an exception pages describe generic AND matching between criterion types, but Exclude a website from TLS inspection explicitly says that source and destination exceptions cannot be combined. The exact scope of that restriction is unclear; generic matching logic does not establish permission. Combining Source IP addresses and Destination IP addresses is therefore not a verified permitted recipe. Before enabling a TLS exclusion, confirm the actual SFOS build, DPI/proxy path, required bypass and narrow host/category scope. Keep the pilot source plus confirmed hostname/category approach above, without adding a destination-IP criterion. A destination plus confirmed hostname/category is a separate option only if its client scope is independently bounded and approved. Do not replace the intended restriction with a source-only exception or simply remove a criterion to make it match: that broadens the protection bypass. If both source and destination IP restrictions are required, stop without enabling or widening the exclusion and obtain build-specific clarification from Sophos Support with the firewall owner.

Default exceptions support software updates and other important website functions. Under Web > Exceptions, Edit opens an existing exception; Clone creates a copy. Check every inherited criterion and skip option before enabling it. Web > General settings controls general HTTPS certificate validation; an individual certificate exception does not replace that baseline setting.

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.

This does not authorize using Policy checks to lift the documented absolute block for highly objectionable criminal activity described above.

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.

Open Policy tester under Diagnostics > Tools, in the Pop-out tools section. Its Firewall, SSL/TLS, and web test method helps identify the expected firewall rule, SSL/TLS inspection rule, and web policy. However, it only tests web traffic in transparent mode, so it doesn’t represent an explicit direct web proxy flow. Always confirm that the Web Exception actually applies with a newly generated request and real logs.

For log evidence, Log firewall traffic must be on in the firewall rule; also turn on Log connections in an SSL/TLS inspection rule. Under System services > Log settings, the relevant log types must be on for Local reporting. Then narrow Log Viewer to the test time and source IP address, and compare the Web filter and SSL/TLS inspection modules with the Firewall Rule ID, policy, and action. Use Sophos Firewall Log Viewer correctly explains the controls. If the entire view remains empty, follow Log Viewer isn’t updating rather than widening the exception on suspicion.

Narrow down errors systematically

Exception doesn’t apply

• The documented absolute category block is not a matching error. An intentionally hidden domain name is not a logging defect in this case. Web categories and web policies explain the boundary; don’t try a broader exception or tests against this content.
• 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.

If the WebAdmin tools don’t isolate the cause, Map Sophos Firewall service logs correctly maps DPI, proxy, malware, and zero-day logs to the affected protection path. Debug isn’t enabled as the first step.

High CPU usage and slow web access after regex changes

Under Diagnostics > System graphs, first compare the timing and load history with slow requests and recent exception changes. In Web > Exceptions, check Selection criteria or Matching URLs for all active exceptions: are ^, escaped hostname dots, or a clear host boundary missing? Are there broad wildcards or many unanchored domain strings?

With authorized console access, run the following read-only command under Device Management > Advanced Shell. It shows current process load without changing any configuration; exit the display with q.

top

If awarrenhttp or snort appear at the top of CPU usage, Web Exception regex may contribute to the load. This is an indication, not proof of the sole cause: both processes perform other checks. Investigate load, requests, and patterns together, make only a limited change, and measure again under comparable traffic load. If CPU usage remains high, continue narrowing down other causes in the affected protection path; don’t indiscriminately disable inspection or all exceptions as a comparison test.

Selectively repair existing regex

For a few exceptions, Web > Exceptions > Edit is the clearest route. First preserve names, enabled state, criteria, and skip options; then correct only the tested URL pattern. For many entries, export the WebFilterException module instead. This export includes the selected Web Exception configurations, not automatically just the faulty exception. Unchanged entries must also be preserved in the before/after comparison.

Before either import variant, safely retain a current firewall backup and an unchanged selective export. Establish the rollback path, maintenance window, and administrator access before importing. A selective export is no substitute for a full backup. Keep the original file, working copy, and approved result separately; configurations and generated reports contain internal details and belong only on an approved, access-protected administrator workstation.

Export WebFilterException and check it with Config Studio

1. On the same firewall, open Backup & firmware > Import export and select Export selective configuration.
2. Use Add new item to search for WebFilterException and confirm with Apply selected items. Do not select Include dependent entity: other configuration areas must not be edited alongside it.
3. Use Export or Download to save the API-[timestamp].tar archive. Extract a working copy; it contains Entities.xml.
4. Open Sophos Firewall Config Studio. Select Configuration editor and Rules > Web exceptions, then use Import to load the selective Entities.xml.
5. In Config Analysis, look for Bad regex. Open the affected entry with Edit, review the suggestion using Apply Fix, and confirm with Update. Don’t change names; a changed name causes the firewall import to create a new exception rather than update the existing one.
6. Check the suggestion with positive/negative cases and long non-matches. For new host patterns, Exact host only and Domain + all subdomains distinguish the intended scope; the repair must not incidentally allow subdomains. An automatic correction replaces neither this decision nor testing the protection impact.
7. Under Preview, check the import configuration against the original: only approved regex should change, not names, sources, destination criteria, enabled state, or skip options. Save the approved archive through Download > Download TAR.

Config Studio processes configuration data in the browser on the endpoint; parsing, analysis, and report generation do not upload this data externally. Local files, downloads, and HTML reports nevertheless remain confidential. Don’t transfer configurations to other online analysis tools. Editing or downloading in Config Studio does not yet change anything on the firewall.

Alternative: edit Entities.xml in a controlled manner

Without Config Studio, edit the same selectively exported working copy in a text editor. Change only the affected URL patterns; don’t perform a blanket replacement of every dot in the XML file. Keep the XML structure, object names, and other fields unchanged. Before packaging, check XML well-formedness and the complete diff. Don’t import if the syntax is unclear or unexpected additional files appear.

Keep the filename exactly Entities.xml and package the files in a new TAR archive with the same structure as the original, not in ZIP or beneath an extra directory. If the original contains other files, don’t silently discard them. Don’t apply this simple Web Exception procedure to unrelated modules or sensitive, interdependent objects.

Import, verify the effect, and roll back

Importing overwrites matching existing settings. A successfully uploaded archive proves neither a narrow match nor unchanged protection. Approve the diff first, then import within the agreed maintenance window.

Under Backup & firmware > Import export > Import, use Browse to select the checked .tar and run Import. Check import messages for errors; then, under Web > Exceptions, compare entry names and counts, enabled state, Matching URLs, criteria, and skip options with the intended state. Settings without a matching import entry remain in place; importing does not automatically remove unwanted additional exceptions.

Then create new connections, repeat the existing positive/negative tests with logs, and, for a performance repair, compare CPU history and process load with the baseline. If errors occur, stop the rollout and disable the affected exception in a controlled manner if the application impact is acceptable. For targeted restoration, the unchanged selective export from the same firewall can be imported; first rule out intervening changes, as these would otherwise also be overwritten. Don’t reactivate a demonstrably overbroad previous state without checking it. A full backup restore remains a separately planned emergency path, not the first rollback step for an individual regex. After every rollback, recheck the configuration and protection path.

Plan WebFilterException via the XML API

The selective import of Entities.xml above is not a general XML API recipe. The object references for SFOS 22.0 and 23.0 describe Add Web Filter Exception / Update Web Filter Exception using the WebFilterException object. The mappings below help review planned automation; they are not a complete, ready-to-send request. Access, protected credentials, an explicit operation, a version-specific request envelope, and safe response evaluation are covered by the central workflow in Use the XML API safely. Do not write without syntax confirmed for the specific build.

Distinguish activation, skip flags, and DomainList

Enabled activates the exception and accepts on or off. The five skip flags also accept on or off, but indicate skipping a check, not enabling it: HttpsDecrypt for HTTPS decryption, VirusScan for malware scanning, PolicyCheck for web policy checks, ZeroDayProtection for zero-day protection, and CertValidation for HTTPS certificate validation. Setting a skip flag to on therefore means bypassing protection. The protection consequences explained above still apply, particularly the automatic zero-day bypass when malware scanning is skipped. Do not infer from a set skip flag that an entry is already active or matches.

The reference shows repeatable criteria under DomainList and separate switches on the object:

• EnableSrcIP with SrcIp: source IP matching; the client belongs here.
• EnableDstIP with DstIp: destination IP matching; the website address belongs here.
• EnableURLRegex with URLRegex: URL pattern matching, not a domain list that automatically includes subdomains.
• EnableWebCat with WebCategory: web category matching.

The four switches are scalar yes/no values, not on/off. The four criteria are string arrays that accept multiple values; the reference specifies a maximum of 43 characters for each entry in SrcIp and DstIp. A populated array alone does not replace a confirmed activation switch. According to the matching logic, different enabled criterion types must match with AND, while values within a type match with OR. Additional URL patterns can therefore broaden the match. The unresolved TLS restriction documented above for combined source and destination IP exceptions remains: the presence of both API fields does not establish that the combination is permitted. Do not create a broader bypass by omitting a criterion.

For URLRegex, start anchors, escaped hostname dots, a clear host boundary, ASCII/Punycode, and positive, negative, and long non-match tests remain required. The pattern in the API reference is not an approved allowlist and replaces neither these tests nor the HTTPS path limitation. XML syntax validation alone does not prove safe matching.

Name is the only parameter marked as mandatory: a scalar string with a maximum of 60 characters; ^, ;, ', ", and \ are excluded. The optional NewName is used for renaming and has the same limits. It is not equivalent to creating a new entry by changing the name during selective import. Desc is an optional scalar string with a maximum of 250 characters; IsDefault identifies a default exception using scalar yes/no and is not permission to modify default objects. The remaining parameters are optional, and their Default columns are blank. This establishes neither a specific default nor a guarantee that omitted values are retained during an update. First preserve the saved state and define the complete intended-versus-actual comparison.

Interpret responses by operation, code, and symbol

Both object references contain exactly these mappings. The operation names and symbols are deliberately left unchanged:

These XML codes are not HTTP status codes. Message.* remains an unresolved documentation symbol, not a verified runtime message or an unambiguous cause of failure. In particular, no numerical maximum may be inferred from Message.WebExceptionsLimit. Add and Update have different success/failure symbols; the Add mappings for 502 and 522 do not carry over to Update.

Securely preserve the actual response together with the operation and XML code, including in the event of a timeout or unclear outcome. Before every write retry, check the entry actually saved using a read-only query confirmed for the specific build or under Web > Exceptions: the old name and, where applicable, the new name, entry count, enabled state, all criteria, and skip flags. Even a reported success does not replace this comparison. If an entry already exists, do not blindly create it again, rename it, overwrite it, or remove criteria. If the state is unclear or partially changed, stop and resolve it with the firewall owner using the response, previous state, and intended state. After a confirmed change, create new connections and run the existing positive/negative tests; only these tests check the protection effect. The central API guide also explains warnings, partial successes, and safe procedures without blind retries.

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