Content filtering is a control that allows or blocks content, such as web pages, email, downloads or messages, based on a policy. It can run in a proxy, a firewall, an email gateway, a DNS resolver or on the device. It enforces rules, but encrypted traffic limits what it can see.
Is content filtering a security control?
Partly. NIST's firewall guidance notes that many firewalls include content filtering features to enforce organization policies not directly related to security, such as acceptable use. Some content filtering is security: blocking known malicious sites, dangerous file types and phishing messages. Some is policy: blocking categories like streaming or gambling at work.
Keep the two apart when you write rules. Security blocks are usually uncontroversial and need fast updates. Policy blocks involve HR and legal and need an owner and an exception process.
Where can the filter sit?
- Web proxy. NIST's HTTP proxy example has requests go to the proxy, which relays them to the web server and may filter for active content. RFC 9110 describes proxies as often used to send an organization's requests through a common point for security services. The proxy sees the request and can apply rules by destination, category or content.
- Firewall or gateway. Some firewalls add filtering of URLs or content on top of packet inspection.
- Email gateway. CISA's phishing guidance recommends email filters, along with antivirus and firewalls, to reduce some malicious traffic.
- DNS. A resolver can refuse to answer for blocked names. It is cheap and works for any application that uses DNS, but it cannot see paths or content.
- The endpoint or browser. It can see content after decryption, and it can follow the device off the corporate network, but it must be installed and kept working on every device.
Each placement trades visibility against coverage. Pick the combination that matches where your users actually are.
What does encryption do to filtering?
A lot. NIST states that firewalls can only work effectively on traffic they can inspect, and that many protocols use cryptography to hide their contents. TLS 1.3, as RFC 8446 says, is designed to prevent eavesdropping, tampering and message forgery. Applied to filters, that means a network device in the middle sees the destination name, maybe, and a stream of ciphertext.
Options, each with a cost:
- Filter by destination only. Simple, but misses content on allowed sites.
- Decrypt and inspect at a proxy. Gives content visibility, but requires deploying a trusted certificate to devices, raises privacy and legal questions, and adds a high value interception point to protect.
- Filter on the endpoint, after decryption. Strong view, more software to manage.
NIST says an organization should have a policy for how to handle encrypted traffic that is not authorized, either permitting or blocking it. Write that policy down before buying anything.
What does a bad rollout look like?
Constructed example: a company blocks a category called "file sharing" at the proxy. A designer cannot receive a client's files and uses a personal phone hotspot to get them, and the files land on an unmanaged laptop. The filter pushed the work outside every control. The fix was an approved sharing tool and a quick exception route, not a stricter block.
How to check or apply this
- Separate security blocks from policy blocks in a written list, with an owner for each.
- Decide which placements you need: proxy, DNS, email, endpoint. Cover remote staff.
- Decide your encrypted traffic stance and document it.
- Start in monitor mode for new categories. Review what would have been blocked for two weeks.
- Create a fast exception process and measure how long it takes.
- Log blocks and allow decisions, and review top blocked categories and false positives monthly.
- Test with known benign and known test pages from a pilot group before wide rollout.
- Review rules at least yearly. Categories and threats change.
Quick check
Can content filtering inspect HTTPS traffic?
Only if the traffic is decrypted somewhere, at a proxy or on the endpoint. Otherwise the filter can act on destination information but not on content.
Is DNS filtering enough?
It blocks known bad names cheaply, but it cannot see URLs or content, and it is bypassed by direct IP connections or other resolvers unless you control those paths.
Sources
- NIST SP 800-41 Rev. 1, Guidelines on Firewalls and Firewall Policy
- RFC 9110, HTTP Semantics
- RFC 8446, TLS 1.3
- CISA, Avoiding Social Engineering and Phishing Attacks
Last reviewed: 18 October 2026.
