URL filtering reads the full web address, not just the domain. Doing that on encrypted traffic means decrypting it, and that single requirement decides whether the control is worth deploying.
The short answer
URL filtering inspects the complete web address a user requests and decides whether to allow it, block it, warn the user or simply log it. Because it sees the path rather than only the domain, it can permit one part of a site and refuse another. Nearly all web traffic is encrypted, so this depth of visibility depends on inspecting inside TLS.
Deployed without that inspection, URL filtering quietly degrades into something you already have.
On this page
What URL filtering sees
| Input | What the decision uses |
|---|---|
| Category | A classification of the site or page, such as file sharing, webmail, social or gambling |
| Reputation | A risk score based on age, hosting history and observed behaviour, which catches sites too new to be categorised |
| Path | The specific page or endpoint, which is what allows one section of a site to be treated differently from another |
| File type | The extension being requested, so executables can be refused while documents are permitted |
| User or group | The same address treated differently depending on who is asking, tied to identity |
The five enforcement actions
Unlike a name lookup, which either resolves or does not, a web request can be handled in several ways.
| Action | When to use it |
|---|---|
| Allow | Permitted, with the request logged for later review |
| Block | Refused outright, with a page explaining why. Reserved for genuine risk and clear policy breaches |
| Warn and continue | An interstitial page the user can click past. Records that they were told, which changes behaviour without generating support tickets |
| Log only | No enforcement, full visibility. The correct first phase of any rollout |
| Quota | Time or bandwidth limits on a category rather than an outright ban |
Start in log only, then warn, then block
Blocking on day one produces a queue of exception requests and a security team that becomes the reason people cannot do their jobs. Running in log-only mode for a few weeks shows what staff genuinely use, which categories are noise and which single sites need permitting before enforcement begins. Warn-and-continue then handles most acceptable-use cases on its own, because very few people click through a warning page to reach something they should not.
The decryption problem
Encrypted traffic hides the path. To read it, the filter terminates the connection, inspects, and re-encrypts, which requires its own certificate authority to be trusted on every device.
| Cost | What it means in practice |
|---|---|
| Certificate deployment | A root certificate installed and maintained on every managed device. Unmanaged and personal devices cannot be covered |
| Certificate pinning | Many applications refuse a substituted certificate by design and simply stop working, producing a permanent exclusion list |
| Privacy and legal exposure | Banking, health and personal accounts are typically excluded, both for law and for staff trust |
| Performance | Every session is terminated and rebuilt, which adds latency and requires capacity |
| The exclusion list | Each exception becomes a channel nobody inspects, and attackers are aware of which categories are conventionally excluded |
Without decryption, URL filtering is domain filtering
An undecrypted filter can read only the hostname exchanged during connection setup. It cannot see the path, cannot distinguish one page from another on the same site, and cannot inspect a file being downloaded. That is precisely the visibility DNS filtering already gives you, at far lower cost and with no certificate estate to maintain. Deploying URL filtering without a decryption decision is paying proxy prices for domain-level results.
URL, DNS and web filtering
| Property | URL filtering | DNS filtering | Secure web gateway |
|---|---|---|---|
| Sees | The full path and file requested | The domain only | Path plus the content of the response |
| Acts | During the request | Before any connection | Throughout the session |
| Needs decryption | Yes, for real depth | No | Yes |
| Covers non-web traffic | No | Yes, anything resolving a name | No |
| Enforcement options | Allow, block, warn, log, quota | Resolve or refuse | Full policy including content actions |
| Cost and complexity | Moderate | Low | High |
Content filtering is the umbrella term for all three. A secure web gateway is effectively URL filtering plus malware inspection of the response body, and in a SASE architecture that gateway is the delivery vehicle for both.
Where Osto fits
Osto is not a full proxy gateway. There is no break-and-inspect deployment and no certificate authority to roll out across your fleet, which is a deliberate choice rather than a gap: for a team of thirty, the maintenance and exclusion list of a decrypting proxy usually costs more than it returns.
Content filtering runs in the endpoint module, so category and reputation policy travels with the laptop instead of applying only inside an office network. Around it, DNS filtering catches anything that resolves a name including non-browser traffic, endpoint protection handles what a downloaded file does once it lands, device control governs where data can be copied, and data loss prevention covers what leaves.
That combination reaches most of what a web filtering policy is actually bought to achieve, without the decryption estate. Events land in one SIEM, and the resulting records support the acceptable-use and malicious-code controls sampled under SOC 2, ISO 27001 Annex A and HIPAA.
Platform walkthrough
Web policy without a proxy to run
Content and DNS filtering enforced on the device, with endpoint protection, device control and data loss prevention behind them. One owner, one dashboard.
Book a demoEvidence from live controls · 200+ frameworks mapped · One platform, everything
Frequently asked questions
What is URL filtering?
A control that inspects the full web address requested and applies policy to it, allowing, blocking, warning or logging based on category, reputation, path, file type and who is asking. Seeing the path is what separates it from domain-level filtering.
What is the difference between URL filtering and DNS filtering?
DNS filtering sees the domain and acts before any connection, covering all protocols at low cost. URL filtering sees the full path during the request and can treat two pages on the same site differently, but needs decryption to do so.
Does URL filtering require TLS inspection?
For anything beyond the hostname, yes. Without it the filter reads only the domain from connection setup, which is the same visibility DNS filtering provides far more cheaply.
What is the difference between URL filtering and a secure web gateway?
A gateway is the broader product. It performs URL filtering and adds malware inspection of the response, data loss controls and often cloud application policy. URL filtering is one function inside it.
Should you block or warn?
Warn for acceptable-use categories and block for genuine risk. Start in log-only mode to learn what staff actually use, then move to warnings. Very few people click through a warning page to reach something they know they should not.