A cloud access security broker (CASB) and a secure web gateway (SWG) both sit between users and the internet, yet they protect different things, and buying one in the belief that it covers the other leaves either SaaS data or web traffic uncontrolled. An SWG governs outbound web traffic from your users: which sites they reach, what they download and what they upload. A CASB governs your use of cloud applications: which apps are in use, what happens to data inside sanctioned tenants, and which third-party integrations hold access. This guide compares them by risk, not by product label: inline versus API inspection, tenant controls, OAuth app visibility, what each misses, and how both converge in a security service edge (SSE). It is for security architects, SaaS security owners and buyers. For each control in depth see the CASB Guide and the Secure Web Gateway and Web Filtering Guide; for platform architecture see the SASE and SSE Guide.
Key takeaways
- The SWG controls the path, the CASB controls the app. An SWG decides whether a request, download or upload is allowed; a CASB knows what a given SaaS app is, which tenant it belongs to, and what is stored and shared inside it.
- Only API-mode CASB sees what never crosses your network. Data shared externally from a sanctioned tenant, files uploaded from a personal device, and OAuth grants to third-party apps are invisible to any inline gateway.
- Tenant restriction is a joint job. Stopping uploads to a personal instance of a sanctioned app needs an inline proxy that decrypts traffic and inserts the SaaS provider's tenant header, which is where SWG and inline CASB meet.
- Neither sees API-to-API traffic. A stolen integration token used from attacker infrastructure never touches your gateway; only SaaS-side logs, CASB API connectors and token governance address it.
- SSE merges the products, not the decisions. One platform can host both, but you still decide per risk whether control is inline, API or SaaS-native, and you still steer traffic and grant API access for each.
The short answer
If your main risks are malware, phishing sites and uncontrolled browsing, an SWG covers most of it. If your main risks are data inside SaaS (oversharing, personal tenants, risky third-party apps, compromised SaaS accounts), you need CASB functions, and the API mode in particular. Most organisations above a few hundred users need both, increasingly bought as one SSE platform. The rest of this page maps each risk to the control that actually closes it.
What each sees
| Dimension | Secure web gateway | CASB inline (forward or reverse proxy) | CASB API mode |
|---|---|---|---|
| Where it sits | Forward proxy on the user's outbound path | Forward proxy for managed devices, or reverse proxy via the identity provider | Out of band, connected to the SaaS provider's admin APIs |
| Traffic it sees | All steered web traffic, any site | Traffic to cloud apps it recognises, with app-specific parsing | No traffic; it reads tenant data, logs and settings |
| Understands app actions | Coarse: URL, method, file type | Fine: share, upload, download, post, instance and tenant | Fine, after the event, from audit logs |
| Data at rest in SaaS | No | No | Yes: scan, label, quarantine, remove external shares |
| Third-party OAuth grants | No | No | Yes, where the SaaS API exposes them |
| Unmanaged devices | Only on networks you control | Reverse proxy for browser sessions | Yes, because it reads the tenant regardless of device |
| Timing | Real time, can block | Real time, can block or restrict | Near real time to hours, remediates after the event |
| Dependency | Traffic steering and TLS inspection | Steering or identity provider redirect, TLS inspection | Admin-level API access in each tenant |
Risk-by-risk: which control closes it
| Risk | Primary control | Supporting control | Notes |
|---|---|---|---|
| Malware download, drive-by compromise (T1189) | SWG | Endpoint protection | URL reputation, file scanning and sandboxing are SWG functions |
| Phishing and credential harvesting sites | SWG | Phishing-resistant MFA | Newly registered and uncategorised domain policies |
| Shadow SaaS discovery | CASB discovery fed by SWG or firewall logs | Endpoint agent telemetry | Discovery depends on log coverage; remote users need agent or SSE logs |
| Blocking an unsanctioned app | SWG enforcement | CASB app catalogue and risk score | Marking an app unsanctioned in a CASB blocks nothing without an enforcement point |
| Upload to a personal instance of a sanctioned app (T1567.002) | Inline proxy with tenant restriction headers | Inline DLP | See the tenant controls section |
| Oversharing inside a sanctioned tenant | CASB API | SaaS-native sharing settings | Inline controls never see a share made from a phone at home |
| Risky third-party OAuth app (T1528) | CASB API and SaaS-native consent controls | Identity governance | Inline controls see the consent page at most, not the token's later use |
| Compromised SaaS account (T1078.004) | CASB API activity analytics | Identity provider risk signals | Mass download or impossible travel from SaaS audit logs |
| Stolen integration token used server to server (T1550.001) | SaaS-side logs, token governance | CASB API | No gateway in the path at all |
| Data loss in web forms and generic upload sites | SWG inline DLP | Endpoint DLP | Applies to any site, not just recognised apps |
Threat model for each
SWG
The SWG assumes the threat arrives over the web to a user, or leaves through the web from a user. It is strong against hostile destinations and content, and weak where the destination is trusted: a reputable SaaS domain carrying a personal tenant, a sanctioned app being misused, or traffic that never passes the proxy. Its blind spots are traffic that is not steered (unmanaged devices, split tunnels, apps that ignore proxy settings, QUIC on UDP 443 where it is not blocked) and anything that happens inside the SaaS provider.
CASB
The CASB assumes the asset is the SaaS tenant and its data. In inline mode it adds app awareness to the path: it can allow viewing but block downloading, or allow the corporate instance and block the personal one. In API mode it adds the view from inside the tenant: who shared what with whom, which apps hold tokens, which accounts behave oddly. Its blind spots are apps with weak or no APIs, apps outside its catalogue, native desktop and mobile clients that bypass reverse proxy sessions, and generic web risk that has nothing to do with a known app.
Architecture in words
- Steering. Managed devices send web traffic to the SWG through an agent, PAC file or tunnel. The same path carries inline CASB policy for recognised apps. Unmanaged devices are reached only through the identity provider, which redirects sign-in to a reverse proxy for browser sessions.
- TLS inspection. Both inline functions need decryption to see URLs, files and tenant identity. Exempt categories (health, banking, pinned apps) are decided once, in one policy.
- Policy evaluation. URL category, reputation and file verdicts come from the SWG engine; app, instance, activity and tenant come from the CASB app catalogue; DLP is ideally one engine used by both.
- API connectors. Separately, the CASB connects to each sanctioned SaaS tenant with an admin-consented application or token and reads files, sharing, audit logs and app grants.
- Logs and response. Gateway logs feed discovery and the SIEM; API findings feed SaaS remediation and incident response.
NIST SP 800-215, Guide to a Secure Enterprise Network Landscape (November 2022), treats cloud access security, SWG, zero trust network access (ZTNA) and SASE as parts of the same move away from a single perimeter. That is the architecture reason both functions now sit in SSE platforms.
SaaS tenant controls: where SWG and CASB meet
A URL block cannot separate a corporate account from a personal one on the same SaaS domain. Major SaaS providers solve this with a header that an inline proxy adds after decrypting sign-in traffic. Providers are listed alphabetically.
| Provider | Feature and header | Where the proxy applies it | Documented scope |
|---|---|---|---|
| Google Workspace | Block access to consumer accounts; header X-GoogApps-Allowed-Domains with allowed domains and optional values such as consumer_accounts and visitor_accounts | Every *.google.com request, with SSL interception and the proxy root CA trusted on clients | Blocks sign-in with accounts outside the list; services that need no sign-in, such as Search and YouTube, stay reachable; also applies to Google Cloud console and gcloud sign-in |
| Microsoft Entra ID | Tenant restrictions v2; header sec-Restrict-Tenant-Access-Policy: <TenantId>:<policyGuid> | Sign-in domains login.live.com, login.microsoft.com, login.microsoftonline.com and login.windows.net, with TLS interception | Proxy insertion enforces the authentication plane; Microsoft documents client-side signalling through Windows Group Policy or its own SSE client for data plane coverage, and advises blocking onedrive.live.com at the proxy |
Practical points from both providers' documentation: the header only works if all relevant traffic is steered and decrypted, anonymous access paths need separate controls, and policy changes (for example migrating from Microsoft's older Restrict-Access-To-Tenants header) must be coordinated between the proxy team and the SaaS administrators. Whether the header is inserted by a product called an SWG or by an inline CASB matters less than having one owner for it.
OAuth app visibility: the API side
Third-party apps that users connect to SaaS tenants hold tokens that work without any user session and from anywhere. An inline gateway may see the consent screen; it does not see the token used afterwards. Visibility needs two layers: SaaS-native consent controls and CASB API discovery across tenants. Providers are listed alphabetically.
- Google Workspace: Admin console, Security, Access and data control, API controls. Apps can be set to Trusted, Limited or Blocked; restricting a Google service revokes tokens of untrusted apps; Gmail and Drive can restrict high-risk OAuth scopes; the Accessed apps list shows which apps users have connected, with a documented delay of 24 to 48 hours for new authorisations.
- Microsoft Entra ID: Enterprise apps, Consent and permissions, User consent settings. Microsoft recommends allowing user consent only for verified publishers and low-impact permissions you classify, with the admin consent workflow for everything else.
A CASB API connector adds a cross-tenant inventory, risk scoring and alerting on new high-privilege grants. The Salesloft Drift incident shows why this matters: stolen OAuth tokens from a chatbot integration were used to call Salesforce APIs as the trusted app, with no gateway in the path. See the Salesloft Drift breach and the SaaS and OAuth App Governance Guide.
Failure modes of each
- SWG without app awareness: allows the whole SaaS domain to keep the corporate tenant working, and so allows the personal tenant too.
- SWG bypass: roaming laptops without an agent, split tunnels for "trusted" SaaS, and proxy-unaware apps leave large gaps that discovery reports then under-count.
- CASB discovery without enforcement: a long list of unsanctioned apps with risk scores and no blocking, because nobody connected the CASB to the gateway or endpoint.
- Reverse proxy assumed to cover everything: session controls apply to browser sessions; native clients sign in directly unless access policies block them.
- API connectors under-scoped or over-privileged: read-only connectors cannot remediate; full admin connectors become a high-value non-human identity. See the SSPM vs CASB guide for posture overlap.
- Two DLP engines: different classifiers in SWG and CASB give different verdicts on the same file, and users learn which path is softer.
Decision criteria
| Your situation | Start with | Add next |
|---|---|---|
| Small organisation, few SaaS apps, mostly managed laptops | SWG or protective DNS with SaaS-native sharing and consent controls | CASB API for the main collaboration suite when data volumes grow |
| Heavy collaboration suite use, external sharing common | CASB API on the suite | Inline tenant restriction through the gateway |
| Regulated data, contractors on unmanaged devices | Reverse proxy session controls plus CASB API | SWG for managed staff |
| Malware and phishing are the leading incidents | SWG with TLS inspection and sandboxing | CASB discovery from SWG logs |
| Large enterprise replacing on-premises proxies and VPN | SSE platform with SWG, inline CASB, API CASB and ZTNA on one policy and DLP engine | SSPM and OAuth governance across all major tenants |
Small versus large: small organisations get most value from SaaS-native controls (consent settings, sharing defaults, tenant headers inserted by whatever proxy they run) and one gateway. Large organisations need one policy model across both functions; otherwise SWG and CASB rules drift apart, and exceptions in one undo the other.
Worked scenario: 1,500 staff, hybrid working
A professional services firm runs one collaboration suite, a CRM and about 300 discovered SaaS apps. Incidents: two personal-cloud uploads of client files and one malicious OAuth app consent. It has an on-premises proxy that remote staff bypass.
- Deploy SSE agents to managed laptops so web traffic reaches the SWG from anywhere; keep the old proxy only for on-site servers during migration.
- Insert the tenant restriction headers for the collaboration suite through the gateway, after a pilot group confirms partner collaboration still works.
- Connect the CASB API to the suite and CRM; remove public links to client folders and set alerts on new high-privilege OAuth grants.
- Tighten user consent to verified publishers and low-impact scopes, with an admin consent workflow.
- Use discovery to rank the 300 apps; sanction about 40, block high-risk categories at the gateway, and coach on the rest.
Result: personal-tenant uploads are blocked inline on managed devices, external sharing is controlled from the tenant side for all devices, and OAuth grants are visible across both tenants.
Where identity fits
Both controls depend on identity. Inline policy uses the user and device identity from the identity provider; reverse proxy control exists only because sign-in is redirected. API-mode CASB is itself a non-human identity holding powerful tokens in your most sensitive tenants, and the OAuth apps it inventories are non-human identities too. Govern the connector credentials and third-party grants like privileged accounts. See OAuth and SaaS integration breaches.
Implementing both without duplicating work
- Map risks to controls using the risk table above; record the owner of each control.
- Fix steering first. Measure the share of managed-device web traffic reaching the gateway before relying on any inline policy.
- Connect APIs early. API connectors give value on day one with no user impact; start read-only, then grant remediation scopes where justified.
- Pilot inline controls in monitor mode with a small group, then a wider ring, before blocking.
- Unify DLP so one classifier and one set of policies apply inline and through APIs.
- Keep rollback ready: tenant headers and blocking policies can be removed in one change, and pilot rings can return to monitor mode quickly.
Detection and measurement
- Steering coverage: share of managed devices sending traffic to the gateway in the last 24 hours.
- Tenant header coverage: share of sign-ins to covered SaaS providers that carried the header.
- Unsanctioned app usage trend: users of blocked or unsanctioned apps over time.
- External sharing exposure: count of publicly or externally shared sensitive files in sanctioned tenants, and median time to remediate.
- OAuth grant hygiene: high-privilege third-party grants without a named owner or review in the last 12 months.
- Policy bypass events: TLS inspection exemptions, proxy bypass rules and session control failures logged per week.
Framework mapping
| Framework | Reference | SWG | CASB |
|---|---|---|---|
| NIST CSF 2.0 | ID.AM-02 | Logs feed discovery | Inventory of SaaS services in use |
| NIST CSF 2.0 | PR.DS-02 | Inline DLP on uploads | Inline and API data protection |
| NIST CSF 2.0 | DE.CM-01 | Web traffic monitoring | SaaS activity monitoring |
| NIST SP 800-53 Rev 5 | SC-7, AC-4 | Boundary protection and flow enforcement for web traffic | Flow enforcement per app and tenant |
| NIST SP 800-53 Rev 5 | AC-20, SA-9 | Restricting use of external systems | Governing external system services and their data |
| MITRE ATT&CK | T1189, T1567.002 | Drive-by compromise; exfiltration to cloud storage | Exfiltration to cloud storage (tenant-aware) |
| MITRE ATT&CK | T1528, T1078.004 | Not in the path | Token and cloud account abuse visible through APIs |
Practitioner checklist
- Every SaaS and web risk in your register maps to SWG, inline CASB, API CASB or a SaaS-native control, with an owner.
- Managed-device steering coverage is measured, and bypass paths (split tunnels, QUIC, proxy-unaware apps) are known.
- Tenant restriction headers are inserted for each major SaaS provider where personal tenants are a risk, and tested.
- API connectors cover the main collaboration, CRM and storage tenants, with scoped and monitored credentials.
- User consent for third-party apps is restricted, and high-privilege grants are reviewed.
- Unsanctioned apps are enforced at the gateway or endpoint, not only labelled.
- One DLP policy set applies inline and through APIs.
- Reverse proxy session controls are paired with access policies that block native clients on unmanaged devices.
Standards and references
- NIST: SP 800-215, Guide to a Secure Enterprise Network Landscape
- Google: Block access to consumer accounts
- Google: Control which third-party and internal apps access Google Workspace data
- Microsoft: Tenant restrictions v2
- Microsoft: Configure how users consent to applications
- MITRE ATT&CK: T1567.002 Exfiltration to Cloud Storage
- MITRE ATT&CK: T1528 Steal Application Access Token
Related NHI Mgmt Group resources: CASB Guide, Secure Web Gateway and Web Filtering Guide, SASE and SSE Guide, DNS Filtering vs Secure Web Gateway, Shadow SaaS and Unsanctioned App Discovery Guide.