Cisco Secure Firewall provides advanced URL filtering capabilities that help organizations control and monitor web access by leveraging both manual configurations and Cisco Talos’ powerful reputation and category-based intelligence. With a URL Filtering license, administrators can filter traffic based on over 80 content categories and five reputation levels, offering scalable control that aligns with organizational risk tolerance. Even without a license, manual URL filtering can be configured using specific URL objects, lists, or feeds for more targeted access policies.

Best practices include configuring policies to inspect initial packet flows so the system can identify the application and URL early in the session, especially critical for encrypted traffic. Secure Firewall evaluates HTTPS traffic using metadata such as the server certificate or SNI in the ClientHello message, without needing full decryption, thanks to TLS Server Identity Discovery. For TLS 1.3, which encrypts server certificates, enabling this feature is essential for categorization without decryption.

When crafting policies, admins should prioritize blocking “Threat” categories and low-reputation sites (such as those labeled “Poor” or “Untrusted”), while being cautious with uncategorized or unknown URLs, which may represent emerging threats. Rule order is also crucial: specific exceptions or manual rules should precede broader category-based rules to ensure they take effect.

Note that some platform-specific limitations exist, such as memory constraints on lower-end devices (e.g., Firepower 1010 or Virtual with 8GB RAM), which may lead to increased cloud lookups. Additionally, the Secure Firewall does not parse search query parameters and does not display block pages for HTTPS traffic.

With these considerations, URL filtering becomes a powerful layer of the Secure Firewall’s defense-in-depth strategy which offers visibility, control, and adaptive protection against web-based threats in both encrypted and unencrypted environments.

The Talos Feed in Cisco Secure Firewall provides a continuously updated and highly curated list of categorized URLs sourced from Cisco Talos Intelligence Group, one of the largest commercial threat intelligence teams in the world. This feed underpins the firewall’s URL Filtering capability by classifying web domains into over 80 content categories—such as malware, phishing, adult content, social media, and more – allowing administrators to create precise policies that allow, block, monitor, or restrict access to specific types of web content. The Talos Feed ensures real-time protection against newly discovered malicious or inappropriate sites by delivering constant updates without requiring manual intervention. When enabled, URL filtering policies can dynamically adapt to evolving threats, providing robust, reputation-based web security with minimal administrative overhead.

This post walks you through enabling URL filtering, creating URL objects, applying them to an Access Control Policy, and creating rules based on the Talos Feed.

 

Prerequisites

Before configuring URL filtering, ensure the following:

  • You have a valid URL license installed on the Secure Firewall system.

 

 

Enable URL Filtering Globally

To verify or enable URL Filtering at a global level:

  • Navigate to Integration > Other Integrations

 

  • Ensure that the Enable URL Filtering is enabled.
  • Enable other options as needed:
    • Enable Automatic Updates
    • URL Query Source: Local Database and Cisco Cloud

This integration ensures your system stays current with Cisco’s threat intelligence and URL reputation database.

 

 

Create URL Filtering Objects

To create individual URL objects for custom allow/deny lists:

  • Go to Objects > Object Management > URL 

 

  • Click Add URL > Add Object

 

  • Provide a Name and enter the URL you wish to allow or block.
  • Click Save.

 

 

If you have multiple URLs you would like to reference, you can also create an Object Group for URLs. To do so:

  • Click Add URL > Add Group

 

  • Name the URL group and move the individual objects you would like to include in the group to the Selected URLs column.
  • Click Save.

This object can now be referenced in your access control rules.

 

 

Apply URL Filtering Based on Custom Objects/Object Groups

Once your URL objects are created:

  • Navigate to Policies > Access Control and edit the policy you would like to add a rule to.

 

  • Click the Add Rule button in the Access Control Policy

 

  • Give the rule a name.
  • Set Action to Allow, Block, Block with Reset, Interactive Block, or Interactive Block with Reset
    • The difference between the rules actions for URL are:
      • Allow – Permits access to the URL
      • Block – Silently drops the traffic without any notification to the user. From the end user perspective, the browser will just time out when attempting to pull up the website.
      • Block with reset – This option will drop the traffic and sent a TCP RST (reset) packet so the browser doesn’t have to wait to time out.
      • Interactive Block – This option will display an HTTP response page allowing the user to continue to the website or cancel. It’s seen as a “soft-block” but still allows the user to access the site if they acknowledge the risk and choose to do so.
      • Interactive Block with Reset – This is the same as the Interactive Block option, but if the user chooses not to proceed, or after interaction, the system may send a reset to terminate the session.
  • You can choose to match traffic based on source and destination security zones of interfaces, source and destination networks, ports, applications, users, dynamic attributes, and VLAN tags.

 

  • Go to the URLs tab.

 

  • Click on the URLs subtab to view your previously created objects and object groups.

 

  • Select your previously created URL Object or URL Object Group  from the left and click Add URL.

 

  • Click on Logging to modify the logging settings on this rule.
    • If the rule action is to allow the traffic in any way, the best practice is to enable Log at end of connection
    • If the rule action is to block the traffic, the best practice is to enable Log at beginning of connection.
    • You should never have to enable both on the same rule.
    • You may optionally send this logged connection event to a syslog server, SNMP server, or offload it to Security Analytics and Logging for longterm retention.

 

  • You may also configure a time range if you would like this rule to only apply to a certain time of day or certain days. You can easily configure the time range on the top of the rule if you wish.

 

  • By default, all rules are enabled initially. However, you can optionally turn this off by moving the slider on the top right of the rule to disable the rule until an optimal time that you can test it.

 

  • Click Add to add the rule to the Access Control Policy.

This rule now inspects traffic and allows or blocks access based on the URLs you specified.

 

 

Apply URL Filtering Based on Talos Threat Feeds

  • One again, click the Add Rule button in the Access Control Policy

 

  • Give the rule a name.
  • Set Action to Allow, Block, Block with Reset, Interactive Block, or Interactive Block with Reset. As a reminder:
    • The difference between the rules actions for URL are:
      • Allow – Permits access to the URL
      • Block – Silently drops the traffic without any notification to the user. From the end user perspective, the browser will just time out when attempting to pull up the website.
      • Block with reset – This option will drop the traffic and sent a TCP RST (reset) packet so the browser doesn’t have to wait to time out.
      • Interactive Block – This option will display an HTTP response page allowing the user to continue to the website or cancel. It’s seen as a “soft-block” but still allows the user to access the site if they acknowledge the risk and choose to do so.
      • Interactive Block with Reset – This is the same as the Interactive Block option, but if the user chooses not to proceed, or after interaction, the system may send a reset to terminate the session.
  • Navigate to the URLs tab.

 

  • Click on the URLs sub-tab to view the URL feeds.

 

  • Under this tab are several dynamic threat feed separated by category provided by Cisco Talos. We will add these feeds to our rule to block.

 

  • Since the Action is set to a blocking action, the only logging option available should be to Log at the beginning of the connection. Enable this.

 

  • Click Add to add the rule to the Access Control Policy.

This rule now inspects traffic and allows or blocks access based on the URL feeds you specified.

 

 

Apply URL Filtering Based on Category

  • Click the Add Rule button in the Access Control Policy

 

  • Give the rule a name.
  • Set Action to Allow, Block, Block with Reset, Interactive Block, or Interactive Block with Reset. As a reminder:
    • The difference between the rules actions for URL are:
      • Allow – Permits access to the URL
      • Block – Silently drops the traffic without any notification to the user. From the end user perspective, the browser will just time out when attempting to pull up the website.
      • Block with reset – This option will drop the traffic and sent a TCP RST (reset) packet so the browser doesn’t have to wait to time out.
      • Interactive Block – This option will display an HTTP response page allowing the user to continue to the website or cancel. It’s seen as a “soft-block” but still allows the user to access the site if they acknowledge the risk and choose to do so.
      • Interactive Block with Reset – This is the same as the Interactive Block option, but if the user chooses not to proceed, or after interaction, the system may send a reset to terminate the session.
  • Navigate to the URLs tab.

 

  • On the Categories sub-tab, check the boxes next to the categories that you would like to add to the rule and click Add URL.

 

  • Since the Action is set to a blocking action, the only logging option available should be to Log at the beginning of the connection. Enable this.

 

  • Click Add to add the rule to the Access Control Policy.

This rule now inspects traffic and allows or blocks access based on the URL categories that you specified.

 

Apply URL Filtering Based on Reputation

  • Click the Add Rule button in the Access Control Policy

 

  • Give the rule a name.
  • Set Action to Allow, Block, Block with Reset, Interactive Block, or Interactive Block with Reset. As a reminder:
    • The difference between the rules actions for URL are:
      • Allow – Permits access to the URL
      • Block – Silently drops the traffic without any notification to the user. From the end user perspective, the browser will just time out when attempting to pull up the website.
      • Block with reset – This option will drop the traffic and sent a TCP RST (reset) packet so the browser doesn’t have to wait to time out.
      • Interactive Block – This option will display an HTTP response page allowing the user to continue to the website or cancel. It’s seen as a “soft-block” but still allows the user to access the site if they acknowledge the risk and choose to do so.
      • Interactive Block with Reset – This is the same as the Interactive Block option, but if the user chooses not to proceed, or after interaction, the system may send a reset to terminate the session.
  • Navigate to the URLs tab.

 

  • On the Categories tab, you can click on any specific category of site or Any (Except Uncategorized). 
  • The middle Reputation pane should be available. You can choose a reputation (risk-based) level of a specific category or any category to block or allow and click Add URL to add it to the Selected Destinations and Applications.

 

  • Since the Action is set to a blocking action, the only logging option available should be to Log at the beginning of the connection. Enable this.
  • Click Add to add the rule to the Access Control Policy.

This rule now inspects traffic and allows or blocks access based on the URL categories and reputations that you specified.

 

 

Optional: Configure HTTP Response Pages for Blocked URLs

When Secure Firewall blocks an HTTP request due to a URL filtering rule, you can configure a response page to notify users of the block. This can either be a simple notification or an interactive page that gives users the option to proceed.

However, there are several important limitations and behaviors to be aware of:

  • Only for Web Traffic: Response pages are shown only for HTTP/HTTPS traffic blocked (or interactively blocked) by access control rules or the default access control policy action. Other policy types (e.g., prefilter, SSL, DNS) won’t trigger a response page.
  • No Response Page on Reset: If a connection is blocked with reset, the system sends a TCP RST and does not display a response page. However, if response pages are enabled, they override the reset action, and the page is displayed instead. To ensure resets, disable response pages.
  • Encrypted Traffic Limitations:
    • Encrypted sessions like HTTP/2 or SPDY cannot be decrypted, so no response page is displayed.
    • If SSL policy decrypts traffic, response pages can be shown and are re-encrypted before delivery.
    • If SSL policy is absent or allows encrypted traffic to pass, no response page appears for blocked HTTPS connections.
  • No Response Page on Early or Promoted Rules: Rules that are promoted for performance (simple L3/L4 conditions only) do not trigger response pages.
  • Port 80 to 443 Redirects: If a user accesses a URL without “http/https” and the browser starts on port 80, then redirects to port 443 after accepting the response page, no second response page appears. The original response is cached.
  • URL Not Yet Identified: If the system hasn’t identified the URL before blocking, no response page is shown. This emphasizes the importance of proper packet inspection and SSL policy design.
  • Rule Order Matters: If a Block URL rule is placed after an Allow application rule, the system will not display a response page for that URL.

 

Accessing the HTTP Response Page Settings

To configure response behavior:

  • Navigate to Policies > Access Control > Access Control Policy.
  • Edit the policy you would like to configure the page settings on.

 

  • Click on More from the top menu and choose HTTP Responses from the dropdown

 

  • Here you’ll find two key options:
    • Block Response Page – Displays a static block message when traffic is denied.
    • Interactive Block Response Page – Displays a message with an option for the user to continue at their own discretion.
  • You can choose the System-provided response or upload a custom one. If you choose Custom from the dropdown, you can edit the Block Response Page with your own customizations.

 

 

Dispute A URL Category and Reputation

If you disagree with how a URL is categorized or the reputation that is given to it, you can dispute it with Cisco Talos.

  • Navigate to Integrations > Other Integrations

 

  • Under the Cloud Services section, there is a link for Dispute URL categories and reputations

 

  • On the page that pops up, you can submit a report to Talos to dispute the categorization or reputation.

 

 

Troubleshooting URL Filtering

If URL filtering is not working as expected in Cisco Secure Firewall, here are key steps to validate and troubleshoot the configuration:

1. Confirm License Activation

Ensure that the URL license is:

  • Purchased and registered to your Smart Account.
  • Allocated and applied to the device in Smart Licensing.

Without a valid license, URL filtering capabilities will not be operational.

 

2. Check Global Settings in Cisco CSI Integration

  • Navigate to Integrations > Other Integrations and verify the following:
    • Enable URL Filtering is slide to the active position.
    • Enable Automatic Updates is enabled to keep URL classifications up to date.
    • URL Query Source is set to Local Database and Cisco Cloud

This ensures that your device is capable of evaluating URLs using Cisco’s cloud-based intelligence.

 

3. Understand Limitations with IP-Based Access

Important Limitation: Secure Firewall does not perform DNS snooping or reverse DNS lookups for URL filtering.

What this means:

  • If a user accesses a site using its IP address instead of its domain name, the firewall may not match it against any URL filtering rule. This can potentially allow access to content that should be blocked based on URL.
  • Best practice: Ensure users are not bypassing filters by accessing IP addresses directly, and use additional security intelligence or domain-based restrictions to compensate.

 

4. Expected URL Category Missing from Category List

If you’re searching for a category and can’t find it under URL Filtering:

  • It may belong to Security Intelligence, not URL Filtering.
  • Navigate to the Security Intelligence > URLs tab in your Access Control Policy to confirm.

 

5. Health Alert: “URL Filtering Registration Failure”

  • Ensure the management center and any intermediate proxies can reach the Cisco cloud.

 

6. How to Check a URL’s Category and Reputation

  • Perform a manual lookup using Secure Firewall’s lookup tool.
  • If you receive a “Cloud Lookup Failure”, ensure the feature is enabled and cloud connectivity is intact.

 

7. URL Appears to Be Incorrectly Handled

If access control behavior doesn’t align with a URL’s category or reputation:

  • Verify the URL category and reputation via manual lookup by navigating to Analysis > Advanced > URL.
  • Check these potential misconfigurations in Integrations > Other Integrations:
    • Cached URLs may be outdated — review the Cached URLs Expire setting.
    • Cloud updates might be disabled – enable Automatic Updates.
    • Policy configuration may allow traffic without cloud validation – check Retry URL Cache Miss Lookup.

Also ensure:

  • The Access Control rule is correctly defined and ordered.
  • The local URL database on the management center is updated in Integrations > Other Integrations.
    • To manually update: Go to Integration > Other Integrations then click Update Now.
  • Managed devices are synced and receiving updates from the management center.

 

8. Incorrect Category or Reputation

For Access Control or QoS rules:

  • Use manual URL filtering and ensure proper rule order.
  • For SSL rules:
    • Manual URL filtering is not supported – use Distinguished Name (DN) conditions instead.
    • You can also file a category dispute if you believe the classification is incorrect.

 

9. Web Pages Are Slow to Load

URL filtering introduces slight latency due to cloud lookups:

  • Reduce frequency by extending Cached URLs Expire time.
  • Consider disabling Retry URL Cache Miss Lookup for less cloud dependency.

 

10. Events Missing URL Category/Reputation Data

This typically occurs when:

  • URL rules are not active or missing in your Access Control Policy.
  • Traffic is processed before reaching a rule that includes URL filtering.
  • Even if SSL rules specify URL categories, you must also configure the URLs tab in the Access Control Policy.