Secure Web Gateway (SWG): — How Every Outbound Click Gets Inspected

① What an SWG actually does — the checkpoint on every outbound click

Picture Rahul, an L1 security analyst at Infosys. Every laptop in his org — in the office, at home, at a client site — sends its web traffic through one cloud checkpoint before it touches the internet. That checkpoint is a Secure Web Gateway (SWG). Think of it as the society gate-pass register at the entrance of an apartment complex: every visitor (every outbound request) is checked against the rules before they are let in or turned away. Nothing reaches the internet un-inspected.

An SWG isn't one feature — it's five jobs stacked on the same outbound stream. (1) URL filtering by category: every request's destination is mapped to a category — Gambling, Adult, Malware, Social Networking, Streaming, Business — and a rule allows, cautions or blocks it. (2) Malware scanning: the actual response body is scanned with signatures and heuristics. (3) TLS/SSL decryption + inspection: because most traffic is HTTPS, the SWG decrypts it to do jobs 1, 2, 4 and 5 properly (that's all of Section ②). (4) Sandboxing of downloads: an unknown .exe or macro-laden .docx is detonated in an isolated sandbox and watched before the user receives it. (5) Tenant restrictions: the SWG can force traffic so that only your corporate Google or Microsoft 365 tenant is reachable, blocking a personal Gmail login that could be used to exfiltrate data.

For years job #1 to #5 lived on a physical on-prem proxy box in the data centre. Every branch backhauled its web traffic to that box, got it inspected, then sent it out. With staff now working from home and apps living in SaaS, backhauling a work-from-home laptop in Lucknow through a Mumbai data centre to reach a server in Mumbai is absurd. The cloud SWG moves the checkpoint to a provider's edge (Zscaler ZIA, Netskope, Palo Alto Prisma Access, Cisco Secure Access) near the user, so inspection happens close by and the box-in-the-DC disappears. Same five jobs, no hardware to backhaul to.

The five jobs, one tap each

Tap each card — these are the five reasons a web filter is now called a 'gateway', and every SWG interview starts here.

② TLS inspection — why the SWG must become a man-in-the-middle

Here's the uncomfortable truth that defines a modern SWG: over 95% of web traffic is HTTPS. The payload — the page body, the file you download, the form you submit — is encrypted end-to-end between the browser and the server. So an SWG that only reads the domain name is blind to everything that matters. To scan content, sandbox a download or stop a data upload, it must see inside the tunnel. That requires TLS/SSL inspection.

How can a checkpoint read traffic that's encrypted for the real server? By becoming a deliberate, trusted man-in-the-middle (MITM). The SWG splits the one HTTPS session into two: it terminates the browser's session by presenting its own certificate, and it opens a fresh HTTPS session to the real server. In the middle, for a brief moment, the traffic is in clear text — and that's where the five jobs run.

The trick that makes the browser accept this is the enterprise CA certificate. Your org pushes the SWG provider's (or its own) root CA certificate into every managed laptop's trust store via Intune/Jamf/GPO. Now, when Sneha visits flipkart.com, the SWG generates a fake flipkart.com certificate on the fly, signs it with that trusted CA, and hands it to her browser. The browser sees a cert chaining to a CA it trusts → no warning. The SWG separately validates the real Flipkart certificate on its onward session. If the device doesn't have the CA installed, the user gets a scary certificate-warning page — the #1 symptom of a botched TLS-inspection rollout.

Decryption isn't optional for real security — but it forces a privacy conversation, and that's where do-not-decrypt exceptions come in. Reading a user's online banking session, health portal, or payroll page is both a privacy issue and, in regulated contexts, a compliance one. So mature SWG policy inspects most categories but explicitly bypasses sensitive ones: traffic categorised as Finance, Banking, Health, Government, Legal is set to Do Not Inspect — the SWG still sees the domain and applies URL filtering, but it doesn't crack the payload open. You get security on the 90% and privacy on the sensitive 10%.

③ Steering traffic to the SWG — and where it sits in SSE

An SWG only protects traffic that actually reaches it. So the real-world question on day one is: how do you steer every device's web traffic into the gateway? There are three standard methods, and a mature org uses more than one.

Method 1 — Explicit proxy via a PAC file. A PAC (Proxy Auto-Config) file is a tiny JavaScript file the browser fetches; its FindProxyForURL(url, host) function returns either the SWG's proxy address or DIRECT for traffic that should skip it. You point devices at the PAC URL via GPO/MDM. It's flexible and granular — but a single typo in the PAC logic can send all traffic DIRECT (no inspection) or, worse, loop it. Method 2 — Endpoint client / connector. A lightweight agent (Zscaler Client Connector, Netskope Client, Cisco Secure Client) installed on the laptop tunnels web traffic to the nearest SWG node automatically, wherever the user roams — best for laptops that leave the office. Method 3 — IPsec/GRE tunnel from the edge. The branch firewall/router builds an IPsec or GRE tunnel straight to the SWG, so everything from that site — including guest Wi-Fi, printers and IoT with no agent — is steered without touching each device.

Now place the SWG in the bigger picture. An SWG is one pillar of SSE (Security Service Edge), the security half of SASE. Its siblings: CASB governs your sanctioned SaaS apps and the data in them (the next lesson); ZTNA replaces the VPN for private-app access. The SWG owns the outbound, user-to-internet direction. Critically, because the SWG already decrypts the stream, DLP rides on the same decrypted traffic — the same inspection that scans for malware can also catch a user pasting a customer database or an Aadhaar number into a web form and block the upload. One decrypt, many checks.

function FindProxyForURL(url, host) {
  // Internal + bank → go DIRECT (no SWG)
  if (isInNet(host, "10.0.0.0", "255.0.0.0")) return "DIRECT";
  if (dnsDomainIs(host, ".icicibank.com"))     return "DIRECT";
  // Everything else → send to the SWG, fail open to DIRECT
  return "PROXY gateway.swg.example.net:80; DIRECT";
}

# client fetches the PAC, then for app.box.com:
host=app.box.com  ->  PROXY gateway.swg.example.net:80
host=intranet (10.4.2.9) -> DIRECT
host=www.icicibank.com -> DIRECT   (bank bypass, privacy)
# proxy log: app.box.com  category=File-Share  action=ALLOW  tls=inspected

④ Policy in practice — rules, bypass lists, the gotchas & the cheat-sheet

Time to build real policy. An SWG rule is layered: category + threat + tenant rules evaluated in order, with bypass lists as exceptions. In Zscaler ZIA you build URL rules under Policy → URL & Cloud App Control, and decryption choices under Policy → SSL Inspection. A clean baseline reads like this: block the obvious bad categories (Malware, Phishing, Adult, Gambling), caution the productivity-drainers (Streaming, Social), allow Business, force tenant restriction on M365/Google, and inspect everything except a tight Do-Not-Inspect list (Finance, Health, Government + known cert-pinned apps).

The three classic gotchas that page an L1 at 2 a.m.: (1) Cert-pinned apps break under decryption — Microsoft 365 native clients, WebEx, Dropbox, many banking and Aadhaar/UPI apps pin their certs and refuse the SWG's cert; fix is a Do-Not-Inspect/SSL-bypass entry for their domains. (2) PAC misconfig — a wrong isInNet mask or a missing semicolon sends all traffic DIRECT (silent no-inspection) or breaks the internet entirely. (3) Latency — decrypt + inspect + sandbox adds milliseconds; over-broad inspection of huge streaming/backup flows can feel slow, which is one reason streaming is often Do-Not-Inspect.

One sober, recent note from the real world: because the SWG sits inline on all your web traffic, the provider's platform and your tenant of it are high-value targets. In August 2025, the Salesloft Drift OAuth supply-chain attack (tracked as UNC6395) used stolen OAuth tokens to reach the Salesforce environments of 700+ orgs — including security vendors like Zscaler and Palo Alto Networks — exposing business-contact and support data (Zscaler revoked the integration and rotated tokens). And in 2025, researchers disclosed authentication-bypass flaws across multiple ZTNA/SSE products (e.g. CVE-2025-54982, a SAML signature-validation bypass). The takeaway for you: an SWG is a control you trust deeply, so its admin access, SSO and integrations must be hardened — a compromised SWG tenant can see (and mis-route) everything.

For your certification path, this lesson maps onto the CompTIA Security+ SY0-701 blueprint, where SASE/SSE appears in Domain 3 (Security Architecture). The exam expects you to know that SASE = SD-WAN (networking) + SSE (security), that SSE bundles SWG + CASB + ZTNA, and that an SWG does URL filtering, TLS inspection and malware/sandbox on outbound web traffic delivered from the cloud edge. Get the SWG-vs-CASB-vs-ZTNA boundaries clear and you've locked a reliable cluster of Domain 3 questions.