A single unsafe click can turn a normal workday into an incident response exercise. When you set FortiGate web filtering correctly, employees can still reach the cloud tools, research sites, and customer portals they need, while known malware hosts, phishing pages, risky downloads, and inappropriate categories are controlled before they become a business problem.
Web filtering is not simply about blocking websites. For a business network, it is a practical control that supports productivity, reduces exposure to ransomware, and creates a clearer record of attempted threats. The right configuration depends on your users, applications, compliance requirements, and the FortiGate model and FortiGuard licensing in place.
Start With a Clear Web Access Policy
Before opening the FortiGate dashboard, decide what the organization needs the policy to achieve. A small office may want to block malicious, phishing, gambling, adult-content, and anonymizer categories while allowing most business browsing. A regulated company may need stricter controls for file-sharing, streaming media, personal email, or newly observed domains.
Avoid starting with an excessively restrictive policy. If staff suddenly cannot access Microsoft 365, banking portals, supplier websites, or cloud management consoles, they may use personal hotspots or request emergency exceptions. That reduces visibility rather than improving security.
A sensible baseline is to block high-risk categories, monitor questionable categories, and allow legitimate business traffic. Review logs for at least several business days before tightening controls. This approach gives IT teams evidence for decisions instead of relying on assumptions.
What You Need Before You Set FortiGate Web Filtering
Confirm that the FortiGate appliance is registered and has an active FortiGuard security subscription appropriate for web filtering. Category-based filtering depends on FortiGuard ratings. An expired or insufficient license can leave the business without current category intelligence and reputation updates.
You should also identify the firewall policy that carries outbound user traffic. In many deployments, this is the LAN-to-WAN policy. In larger environments, traffic may pass through separate policies for departments, VLANs, guests, VPN users, or SD-WAN links. A web filter profile only works when it is attached to the policy that the traffic actually matches.
It also helps to document key approved services before making changes. Include accounting platforms, HR portals, cloud storage, video conferencing, industry applications, and supplier domains. This small preparation step reduces avoidable disruption during testing.
Create the Web Filter Profile
In FortiOS, go to Security Profiles and select Web Filter. Create a new profile with a clear name, such as `Corporate-Web-Filter` or `Guest-WiFi-Web-Filter`. Clear names matter when multiple administrators need to troubleshoot or renew services later.
Use FortiGuard categories as the baseline
Enable FortiGuard category filtering and select the actions that fit your policy. For most business users, block categories associated with phishing, malware, botnets, hacking, illegal downloads, anonymizers, and command-and-control activity. Consider blocking newly registered domains if the business has a higher risk profile, since these domains can be used in phishing campaigns before their reputation is established.
For categories that may have legitimate use but are not necessary for every employee, choose Monitor first. Social networking, web-based email, streaming media, and file-sharing services often require a department-by-department decision. Marketing may need social platforms, while finance may not. A separate policy based on user group or VLAN is usually better than one rule applied to everyone.
Add custom URL controls where needed
FortiGuard categories are broad, so use URL filters for specific exceptions or known unwanted destinations. You can allow an approved domain that was categorized incorrectly, block a specific site that does not fit a blocked category, or control subdomains with wildcard matching.
Use exceptions sparingly. An allow rule for an entire broad domain can unintentionally bypass protections for risky pages hosted under that domain. Where possible, allow only the precise hostname or URL path needed for the application.
Static URL filtering is also useful for internal policy enforcement, but it should not replace category filtering. Threat actors change infrastructure frequently, and manually maintained block lists age quickly.
Inspect HTTPS Traffic Without Breaking Business Apps
Most business web traffic is encrypted. If the FortiGate cannot inspect the relevant HTTPS session, its ability to identify URLs, downloads, and web content is limited. This is where SSL/SSH inspection becomes a central design decision.
Certificate inspection provides basic visibility into encrypted sessions without decrypting their full content. It is less intrusive and is often a reasonable starting point. Deep inspection decrypts and examines HTTPS traffic, then re-encrypts it before it reaches the user. This gives stronger protection and more granular enforcement, but it requires careful preparation.
For deep inspection, install the organization’s FortiGate CA certificate on managed endpoints through a trusted device-management method. Without that certificate, users will receive browser certificate warnings. Test business applications, mobile devices, guest networks, and VPN-connected endpoints before enforcing the setting widely.
Some services should be exempted from deep inspection because of certificate pinning, privacy requirements, or application compatibility. Financial services, healthcare systems, and certain software update platforms may require special handling. Do not create broad exemptions simply to eliminate a troubleshooting task. Confirm the exact application and document why the exception exists.
Apply the Profile to the Correct Firewall Policy
After creating the profile, edit the outbound firewall policy that handles employee internet traffic. Enable security profiles and select the new Web Filter profile. If the policy uses proxy mode or flow mode, verify that the profile options and inspection settings are appropriate for that operating mode.
Policy order matters. FortiGate evaluates firewall policies from top to bottom. If a more general allow policy appears above the policy with your web filter, traffic may match the general rule and never receive web filtering. This is a common reason a correctly configured profile appears not to work.
For organizations with different access requirements, create separate policies. For example, corporate employees, guest Wi-Fi users, servers, and remote VPN users should rarely share identical browsing permissions. Guest access often needs stricter limits and should be separated from internal systems. Server networks generally should not have unrestricted web access at all.
Turn On Logging Before You Enforce Blocks
Logging is what turns web filtering from a checkbox into an operational control. Enable logging for the firewall policy and verify that web filter events are visible in FortiGate logs or the organization’s centralized logging platform.
Review blocked events after deployment. Look for repeated attempts to visit phishing or malware sites, unexpected use of anonymizers, and business domains that were categorized incorrectly. Also investigate sudden increases in blocks from one workstation. It may indicate a compromised endpoint, an unwanted browser extension, or a user following a phishing link.
A block page should give users enough information to contact IT when business access is affected. It should not reveal unnecessary details about your security configuration, but it should make the support process straightforward.
Test With Real User Workflows
Do not treat a successful save action as proof that the policy is complete. Test from a device that matches the intended source network and user group. Confirm that normal sites and business applications work, blocked categories are denied, and the expected event appears in the logs.
Test remote users separately. VPN traffic may use a different firewall policy from office traffic, and split-tunnel VPN configurations may send web traffic directly to the internet instead of through the FortiGate. If remote traffic does not traverse the firewall, a web filter profile cannot protect it.
Testing should include software updates, cloud collaboration, voice and video services, file uploads, and authentication portals. These are the areas most likely to reveal SSL inspection conflicts or overly broad URL rules.
Maintain the Policy as the Business Changes
Web filtering needs routine review, especially after new cloud applications, departmental changes, mergers, or security incidents. Remove temporary exceptions once a project ends. Check that licenses are renewed before expiry, and keep FortiOS and FortiGuard updates current within your approved maintenance process.
The most effective configuration is not always the strictest one. It is the one that blocks meaningful risk, gives authorized teams the access they need, and produces logs your IT staff can act on. If your team needs help selecting a FortiGate, validating licenses, or deploying a policy without interrupting operations, Digital World Technology can provide local configuration and ongoing support built around your business requirements.