Securing the Gate with Security Profiles Series: Web Content Filter

Welcome to our comprehensive series on FortiGate Security Profile configuration and deployment named Securing the Gate with Security Profiles. Over the course of this series, we will dive deep into each security profile available on the FortiGate platform, breaking down what they do and providing step-by-step guides on how to configure them effectively.

1. Overview and Architecture

Web content filtering on FortiGate restricts and controls user access to web resources. It is applied through a Web Filter security profile that is attached to a firewall policy. The profile evaluates HTTP and HTTPS traffic against several mechanisms that run in a defined order: FortiGuard category ratings, local category overrides, static URL filters, content (banned word) filters, and a set of advanced web-filter options such as Safe Search enforcement and quota controls.

Two architectural decisions shape every deployment and must be made before anything else: which inspection mode the firewall policy uses (flow-based or proxy-based), and which SSL/SSH inspection profile is applied. HTTPS now accounts for the overwhelming majority of web traffic, so without deep inspection the filter can only see the domain presented in the TLS handshake (SNI), not the full URL or page content.

1.1 The Web Filter Evaluation Order

Understanding precedence prevents the most common misconfiguration, where a static URL allow entry is silently overridden by something else, or a FortiGuard block never fires because an earlier rule already allowed the request. Within a single web filter profile, FortiOS evaluates in roughly this order:

1. URL Filter (static URL list) is checked first. An explicit Allow, Block, Exempt, or Monitor action here can short-circuit later checks. Exempt is the strongest action and bypasses all remaining inspection including antivirus, so it must be used sparingly.
2. Web Content Filter (banned words / patterns) scans the page body for configured words and scores them; the page is blocked when the threshold is exceeded.
3. FortiGuard Category Filter applies the action (Allow, Monitor, Warning, Block) assigned to the category that FortiGuard returns for the rated URL.
4. Local rating overrides and rating options (such as rating images by URL and allowing or blocking unrated sites) adjust how categories resolve.

NOTE: Action precedence within the URL filter list itself is: Exempt, then Block, then Allow (Pass), then Monitor. A more specific Block can be overridden by a less specific Exempt because Exempt is the highest-precedence action. Order your entries deliberately and prefer specific patterns.

1.2 Licensing and Prerequisites

– An active FortiGuard Web Filtering subscription is required for category-based filtering. Without it, FortiGuard categories return as unrated and only static URL and content filters function.
– Verify connectivity to FortiGuard servers before troubleshooting category lookups. The FortiGate must reach the FortiGuard rating service over UDP/53 or UDP/8888 (or the configured port).
– For HTTPS inspection of the full URL and page content, a deep-inspection SSL profile and a CA certificate trusted by clients are required.

Confirm the FortiGuard web filter license and connectivity
get system fortiguard-service status
diagnose debug rating

Test a live category lookup for a URL
diagnose test application urlfilter 1

2. Inspection Modes: Flow vs Proxy

FortiOS supports two inspection modes, set per firewall policy (or per VDOM in older NGFW policy-based mode). The Web Filter profile carries a matching feature set, and the profile feature set must match the policy inspection mode or the policy will not accept the profile.

2.1 Conceptual Difference

Flow-based inspection is handled by the IPS engine using single-pass pattern matching. Packets are inspected as they pass through, without the FortiGate terminating and rebuilding the session. It favors throughput and lower latency, and is the default on most modern builds.

Proxy-based inspection terminates the client session, fully reconstructs the content (the full web page, file, or object), inspects the reconstructed content, and then relays it to the destination. This buffering enables features that flow mode cannot offer, at the cost of more memory and some added latency. A useful mental model is store-and-forward (proxy) versus cut-through (flow).

2.2 Feature Comparison

Capability		Flow-based	Proxy-based
FortiGuard category filtering		Yes	Yes
Static URL filter		Yes	Yes
Content / banned word filter		Limited	Full
Safe Search enforcement		Yes	Yes
Web profile overrides / user overrides		Limited	Full
Quota by category (time / traffic)		No	Yes
Warning and authenticate replacement pages		Limited	Full
Rate images by URL		No	Yes
Block HTTP redirects by rating		No	Yes
Throughput / latency		Higher / lower	Lower / higher
Memory footprint		Lower	Higher
	NOTE  Capabilities shift between FortiOS releases as flow mode gains parity. Always confirm against the FortiOS version you are deploying. As a rule, if you need per-user quotas, full content filtering, or rich replacement-message workflows, choose proxy mode.

NOTE: Capabilities shift between FortiOS releases as flow mode gains parity. Always confirm against the FortiOS version you are deploying. As a rule, if you need per-user quotas, full content filtering, or rich replacement-message workflows, choose proxy mode.

2.3 Setting the Inspection Mode

In recent FortiOS versions the inspection mode is selected directly on the firewall policy via the Inspection Mode toggle (Flow-based / Proxy-based). On builds that expose a system-wide setting, it appears under System > Settings.

config firewall policy
   edit 12
      set name "LAN-to-Internet"
      set inspection-mode proxy or: flow
   next
end

The Web Filter profile declares a matching feature set:

config webfilter profile
  edit "corp-webfilter"
      set feature-set proxy or: flow
   next
end

CAUTION: If the profile feature set does not match the policy inspection mode, the profile will not appear as selectable on the policy and the CLI will reject the assignment. Decide the mode first, then build the profile to match.

3. SSL/SSH Inspection: Seeing HTTPS

Because most sites are HTTPS, the web filter is only as capable as the SSL inspection profile paired with it. There are two levels.

3.1 Certificate Inspection vs Deep Inspection

Aspect	Certificate inspection	Deep inspection (full SSL)
What FortiGate sees	SNI / CN in the certificate only	Full decrypted URL and page content
URL-path filtering	No (domain only)	Yes
Content / banned word filter on HTTPS	No	Yes
Antivirus on HTTPS payload	No	Yes
Client certificate trust required	No	Yes (CA must be trusted by clients)
Breakage risk (pinning, etc.)	Low	Higher; needs exemptions

Certificate inspection is non-intrusive and filters by domain, which is often enough for category blocking. Deep inspection is required whenever you need to filter on the URL path, scan page content, or run antivirus on HTTPS downloads.

3.2 Deploying the CA Certificate

Deep inspection presents a FortiGate-signed certificate to clients. To avoid browser warnings, the signing CA must be trusted by every client. Use a private CA whose root you can push to endpoints, or the built-in Fortinet_CA_SSL certificate distributed through your endpoint management.  Here is an older Article on DPi.

1. Generate or import a CA certificate on the FortiGate (or use the built-in CA).
2. Reference it in the SSL/SSH inspection profile.
3. Distribute the CA root to all clients (AD Group Policy, MDM, or manual import into the OS and browser trust stores).

config firewall ssl-ssh-profile
   edit "deep-inspection-corp"
      set comment "Full SSL inspection for web filtering"
   config https
      set ports 443
      set status deep-inspection
   end
      set server-cert-mode re-sign
      set caname "Fortinet_CA_SSL"
Exempt categories that commonly break under interception
      set untrusted-caname "Fortinet_CA_Untrusted"
   next
end

TIP: Always exempt categories where TLS interception breaks the service or raises privacy concerns, such as Finance and Banking and Health and Wellness. Add certificate-pinned destinations (many software-update and app domains) to the SSL exemption list to avoid breakage.

4. Building a Proxy-Mode Web Filter Profile

This section builds a complete proxy-mode profile end to end. Proxy mode is chosen here because it exposes the full feature surface (quotas, overrides, rich replacement pages). The flow-mode equivalent follows in Section 5.

4.1 GUI Walkthrough

1. Go to Security Profiles > Web Filter and click Create New.
2. Name the profile and set Feature set to Proxy-based.
3. Enable FortiGuard category based filter and assign actions per category .
4. Configure Static URL Filter entries as needed.
5. Under Search Engines, enable Enforce 'Safe Search' on Google, Bing, YouTube.
6. Set additional options: rate URLs by domain and IP, block invalid URLs, block HTTP redirects by rating, and provide details for blocked HTTP 4xx and 5xx errors as desired.
7. Click OK, then attach the profile to a firewall policy together with a deep-inspection SSL profile.

4.2 FortiGuard Category Actions

Each FortiGuard category and subcategory can be assigned one of four actions:

Action	Behavior
Allow	Permit access; no log entry generated for the web filter event by default.
Monitor	Permit access but log the event. Recommended baseline so you gain visibility before enforcing blocks.
Warning	Display an interstitial warning page; the user may proceed after acknowledging. Proxy mode required for the full workflow.
Block	Deny access and present the block replacement message.

A pragmatic starting policy is to Block the security and liability categories, Warning the productivity-drain categories, and Monitor the rest:

config webfilter profile
   edit "corp-webfilter"
      set feature-set proxy
      set web-content-log enable
      set web-filter-activex-log enable
      set web-url-log enable
          config ftgd-wf
               set options error-allow rate-server-ip
Block: Security Risk parent category (e.g. malware, phishing)
          config filters
              edit 1
                  set category 26 #Malicious Websites
                  set action block
              next
              edit 2
                  set category 61 #Phishing
                  set action block
              next
              edit 3
                  set category 26 #Adult/Mature placeholder
                  set action block
              next
              edit 4
                  set category 12 #Games
                  set action warning
                  set warn-duration 5m
               next
               edit 5
                  set category 19 #Information Technology
                  set action monitor
               next
            end
      end
  next
end

NOTE: Category ID numbers vary and are periodically revised by FortiGuard. Do not hard-code IDs from memory; confirm the current mapping in the GUI (hover a category) or with get webfilter categories and the FortiGuard category list for your release.

4.3 Quotas (Proxy Mode Only)

Quotas let you permit a category but cap consumption, either by time or by traffic volume, per authenticated user or per IP. This is ideal for categories like General Interest or Streaming that you want to tolerate but not encourage.

config webfilter profile
  edit "corp-webfilter"
      config ftgd-wf
           config quota
              edit 1
                  set category 12 #category to limit
                  set type time
                  set duration 1h #1 hour of access per day
              next
              edit 2
                  set category 33
                  set type traffic
                  set value 500 #500 MB
                  set unit MB
               next
               end
          end
      next
end

CAUTION: Quotas require an action of Monitor, Warning, or Block on the category, and apply only in proxy mode. Time quotas need a user identity or stable source IP to track consumption accurately, so pair quotas with authentication.

5. Building a Flow-Mode Web Filter Profile

Flow mode is the right choice when throughput is the priority and the advanced proxy-only features are not required. The category filter, static URL filter, and Safe Search all work in flow mode. The configuration is nearly identical apart from the feature set.

config webfilter profile

edit "flow-webfilter"
set feature-set flow
     set web-url-log enable
     config ftgd-wf
         set options rate-server-ip
         config filters
            edit 1
               set category 26
               set action block
            next
            edit 2
               set category 12
               set action block
            next
        end
     end
next
end

config firewall policy
   edit 12
       set inspection-mode flow
       set utm-status enable
       set webfilter-profile "flow-webfilter"
       set ssl-ssh-profile "certificate-inspection"
    next
end

In flow mode the Warning action and quotas are unavailable or limited; if a user-facing warning workflow or quotas are central to the design, move that policy to proxy mode.

6. Static URL Filtering

The static URL filter applies explicit actions to specific URLs, domains, or patterns regardless of FortiGuard category. It is the right tool for known-good internal sites, exceptions to category rules, and targeted blocks. Entries support three match types: Simple (exact substring), Wildcard, and Regular Expression.

6.1 Actions

Action		Effect	Notes
Exempt		Bypass all remaining inspection (web filter, AV, DLP).	Highest precedence. Use sparingly; it is a security hole if overused.
Block		Deny the request and show the block page.	Overrides FortiGuard Allow for matching URLs.
Allow		Permit and continue to other inspection.	Lets a URL pass the URL filter, but FortiGuard and AV still apply.
Monitor		Permit and log the match.	Useful for watching specific domains.
	NOTE  Allow is not the same as Exempt. Allow passes only the URL-filter stage; FortiGuard category filtering and antivirus still run afterward. Exempt skips everything that follows. If you want a site fully whitelisted including AV, that is Exempt, but understand the risk.

NOTE: Allow is not the same as Exempt. Allow passes only the URL-filter stage; FortiGuard category filtering and antivirus still run afterward. Exempt skips everything that follows. If you want a site fully whitelisted including AV, that is Exempt, but understand the risk.

6.2 Match Types and Examples

Type	Example pattern	Matches
Simple	intranet.example.com	URLs containing that exact string.
Wildcard	*.example.com	Any subdomain of example.com.
Wildcard	*.example.com/hr/*	Any path under /hr/ on example subdomains (deep inspection needed for path).
Regex	^https?://ads[0-9]+\.tracker\.net	URLs whose host matches the expression.

6.3 CLI Configuration

config webfilter urlfilter
    edit 1
      set name "corp-url-list"
      config entries
         edit 1
            set url "intranet.example.com"
            set type simple
            set action exempt
         next
         edit 2
            set url "*.knownbad.example"
            set type wildcard
            set action block
         next
         edit 3
            set url "*.partner.com/portal/*"
            set type wildcard
            set action allow
         next
         edit 4
            set url "^https?://ads[0-9]+\.tracker\.net"
            set type regex
            set action block
         next
      end
   next
end

Attach the URL filter list to the web filter profile
config webfilter profile
    edit "corp-webfilter"
        config web
            set urlfilter-table 1
        end
    next
end

TIP: Path-level patterns (anything after the first slash) require deep SSL inspection on HTTPS sites. With certificate inspection only, your effective granularity is the hostname.

6.4 Web Content (Banned Word) Filter

The content filter scans the page body and blocks pages whose accumulated score for matched words and patterns exceeds the threshold. Each pattern carries a score; a page is blocked when the sum of scores for words found on it reaches the limit. This is most effective in proxy mode where the full page is reconstructed.

config webfilter content
      edit 1
      set name "banned-content"
      config entries
         edit "gambling"
            set pattern-type wildcard
            set action block
            set score 25
         next
      end
   next
end

config webfilter profile
       edit "corp-webfilter"
      config web
         set content-header-list 1
         set bword-table 1
         set bword-threshold 10
       end
   next
end

7. Safe Search Enforcement

Safe Search forces search engines to filter explicit results even when the user has not enabled it. FortiGate implements this by transparently injecting the provider’s Safe Search parameters (and, for YouTube, the restriction header) into requests to supported engines: Google, Bing, and YouTube.

7.1 Requirements

– Deep SSL inspection is mandatory. Safe Search works by modifying the HTTPS request to the search engine, which is impossible without decryption. With certificate inspection only, Safe Search cannot be enforced.
– The search engine must be one of the supported providers. Other engines are not enforced.
– For YouTube, an optional restriction level (Strict or Moderate) can be set.

7.2 Configuration

config webfilter profile
   edit "corp-webfilter"
      set options ...
      config web
          set safe-search url header
# ‘url’ rewrites query parameters; ‘header’ adds the YouTube restriction header
          set youtube-restrict “strict or: moderate”
      end
   next
end

In the GUI this is the Enforce 'Safe Search on Google, Bing, YouTube checkbox under the Search Engines section of the profile, with a YouTube restriction dropdown.

CAUTION: Safe Search relies on the search providers honoring the injected parameters. Provider changes can affect behavior, and QUIC/HTTP3 can bypass interception. Block UDP/443 (QUIC) outbound so browsers fall back to TCP/443 where the FortiGate can inspect, otherwise Safe Search and category filtering may be evaded.

7.3 Blocking QUIC to Preserve Inspection

Force browsers off QUIC so TLS is inspectable
config firewall policy
    edit 20
       set name "Block-QUIC"
       set srcintf "port1"
       set dstintf "wan1"
       set srcaddr "all"
       set dstaddr "all"
       set action deny
       set service "QUIC"
       set schedule "always"
    next
end

Place this deny policy above the general internet-access policy so QUIC is dropped before the allow rule matches.

8. User Overrides and Authentication Workflows

Overrides let a user temporarily bypass a block, subject to administrator-defined scope and duration. They are a proxy-mode feature and depend on user identity, so authentication must be in place. There are two related mechanisms: the FortiGuard category override and the web profile override (the user-facing temporary access workflow).

8.1 How an Override Works

When a user hits a blocked or warning page, the replacement message can offer an override option. The user authenticates, and the FortiGate then applies an alternate, less restrictive web filter profile to that user (or their group, IP, or the requested URL) for a defined window. After the window expires, the original profile resumes.

8.2 Override Scope

Scope	Applies the override to
User	The authenticated individual user.
User group	All members of the matched group.
IP	The source IP address that triggered the override.
Ask	Prompts the user to choose at override time (where permitted).

8.3 Configuration

Define the override block inside the web filter profile, specifying the scope, the profile to switch to, and the duration. The profile must be proxy-based and the policy must authenticate users.

config webfilter profile
   edit "corp-webfilter"
      set feature-set proxy
      config override
          set ovrd-cookie deny
          set ovrd-scope user #user | user-group | ip | ask
          set profile-attribute Login-LAT-Service
          set ovrd-dur-mode constant
          set ovrd-dur 15m #15-minute override window
          set profile "relaxed-webfilter"  #less restrictive profile to switch to
          set profile-type list
       end
   next
end
“`

The relaxed profile (relaxed-webfilter above) is an ordinary web filter profile with looser category actions. Authorized users or groups are typically constrained by which users may invoke overrides, configured alongside the firewall policy authentication.

NOTE: Overrides require authentication on the policy (for example, active or captive-portal authentication, or FSSO). Without an identity, user- and group-scoped overrides cannot resolve, and only IP scope is meaningful.

8.4 Local Category Rating Overrides

Separately from user overrides, an administrator can permanently re-rate a specific URL into a different category, which is useful when FortiGuard miscategorizes a site. This changes how the category filter resolves for that URL for everyone.

config webfilter ftgd-local-rating
     edit "misrated.example.com"
     set rating 19  #reassign to category 19 (e.g. Information Technology)
     set status enable
    next
end

Create a custom local category if needed
config webfilter ftgd-local-cat
       edit "corp-approved"
      set id 140
   next
end

9. Proxy Options Profile

The Proxy Options profile (separate from the web filter profile) governs how protocols are intercepted and how content is handled before the security profiles inspect it. It is referenced by the firewall policy and matters most in proxy mode, though some settings apply to flow inspection too.

9.1 Key Settings

Setting	Purpose
Protocol port mapping	Which ports are treated as HTTP, HTTPS, FTP, SMTP, etc. Add non-standard ports (e.g. 8080) so they are inspected.
Comfort clients (clienting)	Sends data trickle to the client during long scans so connections do not time out.
Oversized file / email threshold	Maximum object size the proxy will buffer and inspect; larger objects are passed or blocked per policy.
Block oversized action	Whether to pass or block content that exceeds the inspection size limit.
Chunked bypass	Whether to bypass scanning of HTTP chunked transfers.
HTTP header changes	Add, remove, or rewrite request/response headers (for example, add X-Forwarded-For).

9.2 Configuration

config firewall profile-protocol-options
   edit "corp-proxy-options"
      config http
         set ports 80 8080
         set status enable
         set comfort-interval 10
         set comfort-amount 1
         set oversize-limit 10  #MB before the object is considered oversized
         set options no-content-summary
       end
         set oversize-log enable
       next
end

config firewall policy
     edit 12
      set profile-protocol-options "corp-proxy-options"
   next
end

TIP: Add every non-standard HTTP/HTTPS port your environment actually uses to the proxy options port list. A common cause of bypassed filtering is web traffic on a port the proxy options profile is not watching.

9.3 Comfort Clienting and Large Downloads

In proxy mode the FortiGate buffers an object before scanning it, which can stall a browser on large files. Comfort clienting sends a small amount of data at a set interval to keep the session alive while scanning completes. Tune `comfort-interval` and `comfort-amount` for environments with large downloads.

10. Assembling the Firewall Policy

All the pieces come together on the firewall policy. The policy ties together the inspection mode, the web filter profile, the SSL/SSH inspection profile, and the proxy options profile, and (for overrides, quotas, and per-user logging) authentication.

config firewall policy
   edit 12
      set name "LAN-to-Internet-Filtered"
      set srcintf "port1"
      set dstintf "wan1"
      set srcaddr "corp-lan"
      set dstaddr "all"
      set action accept
      set schedule "always"
      set service "HTTP" "HTTPS" "DNS"
      set inspection-mode proxy
      set utm-status enable
      set ssl-ssh-profile "deep-inspection-corp"
      set webfilter-profile "corp-webfilter"
      set profile-protocol-options "corp-proxy-options"
      set logtraffic all
      set nat enable
   next
end

For an identity-aware policy that supports user overrides and per-user quotas, add an authentication source (FSSO group, local/LDAP group, or captive portal) to the policy so the FortiGate can attribute sessions to users.

11. Verification and Troubleshooting

11.1 Confirm Profile Assignment and Hits

Show the assembled web filter profile
show webfilter profile corp-webfilter

Confirm the policy references the right profiles
show firewall policy 12

Live web filter log view (or check Log & Report > Web Filter in GUI)
execute log filter category 2 #2 = web filter
execute log display

11.2 FortiGuard Rating Diagnostics

Is the rating service reachable and licensed?
diagnose debug rating

What category does FortiGuard return for a URL?
diagnose test application urlfilter 1

Inspect and clear the local rating cache if results look stale
diagnose webfilter fortiguard cache-id
diagnose webfilter fortiguard clear-cache

11.3 SSL Inspection Issues

If sites break under deep inspection, the usual causes are an untrusted CA on the client, certificate pinning, or QUIC bypass.

– Verify the FortiGate signing CA is installed in the client trust store.
– Add pinned domains (many app and update services) to the SSL exemption list.
– Block QUIC (UDP/443) so traffic falls back to inspectable TLS over TCP.
– Exempt sensitive categories (Finance, Health) from deep inspection for privacy and compatibility.

11.4 Common Symptoms

Symptom	Likely cause	Fix
Category filtering does nothing	No FortiGuard license, or rating service unreachable	Verify license and reachability with diagnose debug rating.
URL path block not working on HTTPS	Certificate inspection only	Switch the SSL profile to deep inspection.
Safe Search not enforced	No deep inspection, or QUIC in use	Enable deep inspection and block QUIC.
Profile not selectable on policy	Feature set mismatch	Match profile feature-set to policy inspection-mode.
Quotas never trigger	Flow mode, or no user identity	Use proxy mode with authentication.
Large downloads time out	Proxy buffering without comfort clienting	Enable comfort clienting in proxy options.

12. Deployment Best Practices

1. Start in Monitor mode for most categories, review the logs for a week or two, then tighten to Block and Warning based on real traffic. This avoids a flood of help-desk tickets on day one.
2. Decide inspection mode by feature need, not habit. Choose proxy mode where quotas, overrides, content filtering, or rich warning pages are required; choose flow mode for raw throughput.
3. Deploy deep inspection deliberately. Push the CA to all clients first, exempt pinned and sensitive destinations, and block QUIC so inspection cannot be bypassed.
4. Prefer specific static URL entries and use Exempt rarely. Every Exempt entry is a hole that skips antivirus and the rest of inspection.
5. Pair quotas and overrides with authentication. Without identity they degrade to IP-based behavior, which is unreliable on shared or NAT’d networks.
6. Keep proxy options port lists complete. Add every real HTTP/HTTPS port, or traffic on odd ports slips past filtering.
7. Customize replacement messages so blocked users see a clear, branded explanation and a path to request access, reducing confusion and tickets.
8. Document the evaluation order for your team. Most filtering surprises trace back to URL filter precedence or an Exempt entry overriding a category block.
9. Review FortiGuard categories after major FortiOS upgrades, since category IDs and groupings change between releases.
10. Test from a real client after every change, covering an allowed site, a blocked site, an HTTPS path block, and a Safe Search query.