A cloud access security broker (CASB) serves as a central policy enforcement point positioned between your network users and cloud-based SaaS applications. It sees what crosses that boundary and applies rules to it: who can access which apps, what data can move where, and what behavior looks suspicious.
A CASB can work in two deployment modes. An inline proxy is the inspector at the gate that forces all user traffic to pass through it before reaching the cloud app. CASB API mode is the auditor reviewing shipping manifests after delivery.
The category emerged around 2011–2012 when BYOD adoption and SaaS proliferation created a problem IT couldn't solve with existing tools. Employees were uploading sensitive data to apps procurement never approved, and nobody had visibility into what was leaving the organization or where it was going. Gartner coined the term "cloud access security broker" around 2012 to describe this new market, with vendors like Skyhigh Networks and Netskope (founded in 2012 as a CASB-first company) among the pioneers.
Gartner later folded the standalone CASB Magic Quadrant into the SSE Magic Quadrant, which tells you something about how the market matured. CASB features are now integrated into larger platforms, instead of being a separate category.
The Cloud Security Workflow Handbook
Get the 5-step framework for modern cloud security maturity.
What does a CASB actually do?
CASBs are built around four core functions: visibility, compliance, data security, and threat protection. Each one works differently depending on whether you’ve deployed in API mode or inline proxy mode.
Visibility
A CASB discovers every SaaS app in use across your organization, sanctioned and unapproved. In practice, an API-mode CASB connects to your IdP and SaaS platforms, scans OAuth grant registrations and audit logs, and surfaces a list of apps procurement never approved. Inline mode flags them in real time as users hit them through the proxy. API mode finds shadow SaaS retrospectively in bulk; inline mode catches it as it happens.
Compliance
CASBs enforce regulatory and internal policy controls on SaaS activity: restricting external sharing, blocking file downloads to personal storage, and watermarking sensitive documents. A PCI DSS policy can block file shares to external email domains for any document matching a payment card data pattern. In inline mode, that block happens before the file leaves the organization. In API mode, the CASB detects the share after it happens, quarantines the file, and removes the sharing permission. In other words, inline blocks before exfiltration, while API mode remediates after the fact.
Data security
CASBs apply DLP (data loss prevention) policies to SaaS data in motion through an inline proxy and at rest through API-mode scanning. For example, take an engineer who uploads a CSV containing customer personally identifiable information (PII) to an unsanctioned SaaS platform. With an inline proxy, the CASB intercepts the upload in transit, runs content inspection on the decrypted payload, matches the PII pattern, and blocks it before it reaches the SaaS platform. In API mode, the file lands first. The CASB detects the PII pattern after it arrives, quarantines the file, alerts your team, and removes external sharing permissions.
Threat protection
CASBs detect anomalous user behavior on SaaS platforms using user and entity behavior analytics (UEBA, a system that flags deviations from normal usage patterns). The classic scenario: A user authenticates to Salesforce from New York at 9 a.m. and Singapore at 10 a.m. CASB flags an impossible travel alert, and an analyst investigates whether it’s a credential compromise or a VPN artifact. Both inline and API modes generate these alerts. API mode depends on how fresh the audit log is; inline generates alerts in real time from observed session behavior.
API mode vs. inline proxy
API-mode CASB connects to SaaS platforms via OAuth and REST APIs. It scans data at rest and polls audit logs to detect activity. How quickly it detects something depends entirely on how the SaaS platform delivers events. Some platforms push webhooks that deliver events in near real time. Others export logs on a schedule, which can mean detection lags anywhere from minutes to hours after the actual event. When webhook delivery fails or a platform only supports scheduled log exports, your detection timing falls back to the polling interval.
Inline proxy (forward proxy) mode sits directly in the traffic path between user devices and SaaS destinations. The proxy terminates TLS, decrypts the payload, inspects it, re-encrypts it, and forwards it. For this to work, device traffic must route through the proxy via PAC file or agent enrollment.
To understand the tradeoff of these two approaches, let’s go back to the CSV-upload scenario. A user on a managed device uploads a customer list containing PII to unsanctioned SaaS storage. In inline proxy mode, the CASB intercepts the upload in transit, runs DLP content inspection on the decrypted payload, matches the PII pattern, and blocks the upload before the file ever reaches the SaaS platform. In API mode, the file lands in SaaS storage first. The CASB then polls the audit log or receives a webhook, detects the PII pattern, quarantines the file, removes external sharing permissions, and alerts. All of that happens after the upload is completed.
A reverse proxy mode also exists for apps accessed by externally managed or contractor devices: The CASB intercepts at the app side rather than the device side, which handles partner access scenarios without requiring device enrollment.
The key practical difference: API mode gives you breadth across SaaS platforms with low deployment friction. Inline gives you real-time blocking but requires device management and entails SSL inspection complexity.
Bypass risks and failure modes
CASB inline inspection has four documented bypass paths: QUIC/HTTP3 traffic, certificate-pinned apps, direct-to-IP connections, and unmanaged devices. Some are configuration choices you can address. Others are structural:
QUIC/HTTP3 inspection gaps: CASB inline inspection targets TCP traffic. QUIC, the protocol powering HTTP/3, runs over UDP/443, which most CASBs can’t inspect. Chrome can reach a destination your CASB block policy is supposed to cover because the block only applies to TCP. Google Workspace (Meet, Drive, Chrome) defaults to QUIC when available, making this a specific, documented production security loophole. The standard vendor response is to block QUIC at the proxy and force TCP fallback. Confirm your deployment does this explicitly; don’t assume it’s on by default.
Certificate pinning: Apps that refuse proxy-issued certificates break under SSL inspection. Vendors maintain bypass lists for these apps: banking apps, Apple services, and others that pass through uninspected. These necessary exclusions introduce structural, designed blind spots into your network defense architecture, creating uninspected data pathways that advanced threats can exploit to evade detection.
Direct-to-IP: Requests that skip DNS and connect directly to an IP address bypass proxy hostname–based routing entirely. By eliminating the DNS lookup and hostname match, this traffic circumvents standard layer-7 proxy interception, creating an unmonitored channel that evades URL filtering and policy enforcement controls.
Unmanaged devices: Personal laptops, contractor devices, or mobile devices without MDM enrollment never route traffic through the proxy. Inline inspection is completely absent for those devices. API mode retains some coverage since it talks to the SaaS platform rather than the device. You can detect that an unmanaged user downloaded 500 files from Google Drive via audit log. You can’t block it in transit or inspect file contents.
CNAPP vs. CASB: What’s the difference?
Both CNAPP and CASB protect enterprise IT environments, but businesses have to understand their differences, specifically in terms of focus, capabilities, and operationalization, to make an informed decision about which solution is better for them.
Leggi di più
Other CASB blind spots
Shadow AI
A CASB can block known AI tool domains in inline mode. The harder problem is embedded AI features inside sanctioned SaaS apps. When Microsoft 365 is whitelisted, the CASB can’t see what a user sends to Copilot within that already-approved TLS session. The traffic is inside an allowed destination, so the CASB never inspects the payload.
Standalone AI tools accessed through a browser, like ChatGPT or Claude by direct URL, are blockable if your proxy is in path and the traffic routes over TCP. QUIC routes may slip through, as described in the previous section. The compensating control for embedded AI behavior is browser-level DLP agents or endpoint controls that can inspect browser extension and web app behavior. That’s a separate tool layer, not native CASB coverage.
SaaS-to-SaaS OAuth
When a user authorizes a third-party app to access a primary SaaS platform, that app receives a bearer token: a credential that lets it call SaaS APIs directly without the user being actively present. Those API calls happen server-to-server between SaaS platforms. They don’t route through the user's network session, so neither inline proxy nor API-mode CASB intercepts them. A third-party productivity app granted full Google Drive access can read, copy, and exfiltrate files without generating any CASB alert. The authorization event is visible, but everything that happens afterward isn’t. Some teams audit OAuth grant registrations manually or via SaaS security posture management (SSPM, tools that assess SaaS app configuration and access grants). Some CASB platforms flag high-scope grants as a risk indicator, but post-grant activity remains invisible.
| Tool | What it enforces | What it covers | Key gap |
|---|---|---|---|
| CASB | SaaS user activity, data in motion and at rest | SaaS app usage, data classification, compliance, anomalous behavior | Cloud infrastructure posture, identity entitlement risk, AI workloads |
| SSE/SASE | CASB + web gateway + Zero Trust Network Access in one platform | All of CASB plus web traffic and network access control | CASB depth varies by vendor heritage |
| CSPM | Cloud infrastructure misconfigurations | IaaS/PaaS resource config: S3 buckets, security groups, IAM policies | Does not see SaaS user activity or data in motion |
| CNAPP | Cloud workload posture, identity risk, vulnerability context | Cloud-native workloads: VMs, containers, serverless, IaC (infrastructure as code), AI pipelines | Does not model SaaS user sessions or data moving through a proxy |
| DLP | Data classification and exfiltration prevention | Email, endpoint, SaaS (when integrated), web | Enterprise DLP spans more channels; CASB DLP inspects what crosses the proxy or lands in the SaaS platform, nothing more |
For most enterprises in 2025–2026, CASB capabilities already exist inside a security service edge (SSE) platform. The real question is whether the bundled version is deep enough for your specific SaaS DLP and compliance requirements. If you’re running a regulated workload under HIPAA or PCI DSS with heavy SaaS usage and strict data movement controls, a CASB-heritage SSE platform likely gives you more inspection depth than a general-purpose SSE platform with CASB added on. For most others, the SSE bundle is the answer.
The clean line between CNAPPs and CASBs matters: A CNAPP covers cloud infrastructure (VMs, containers, IaC, AI workloads, and CIEM). A CASB covers SaaS user sessions and data in motion. Data security posture management (DSPM, tools that find and classify sensitive data in cloud storage) lives in the CNAPP layer, not the CASB layer.
Watch 12-min demo
See exactly how Wiz handles a live threat. This 12-minute walkthrough shows you how our Security Graph correlates runtime alerts with cloud context to identify the root cause, find the resource owner, and provide one-click remediation.
Deployment guidance
Start with API mode: There’s no agent rollout, no SSL inspection risk, and no PAC file management to deal with. You get visibility across your SaaS estate within days and can understand your traffic patterns before adding the complexity of inline inspection. The exception is regulated environments where inline blocking is required from day one: Retrospective API-mode remediation does not satisfy a HIPAA or PCI DSS control requirement that demands real-time blocking. In those cases, plan your SSL inspection exemption list before you go live.
Connect your IdP via SAML to give CASB user identity context in policy enforcement: Pair that with SCIM provisioning (a standard that propagates user lifecycle events like new hires and offboarding to connected systems) to keep CASB policies current automatically. Without IdP integration, you’re enforcing policies against anonymous traffic, which makes everything harder to tune and investigate.
Expect the first two weeks to be noisy: Default policies are broad, and behavioral baselines take time to establish. Baseline normal behavior first, then tighten thresholds.
Plan for the most common deployment failure modes: As we’ve seen, these are certificate pinning (banking services and pinned-cert apps break under SSL inspection, requiring an exemption list before enabling full SSL inspection), QUIC fallback not explicitly disabled (Chrome reaches blocked destinations over UDP/443), and PAC file bypass on non-domain-joined devices (traffic never enters the proxy). Build your exemption list and confirm QUIC blocking before rolling out to your full user population.
How Wiz complements CASB
While CASBs do an excellent job securing user sessions and data crossing the network boundary, a complete defense requires deep visibility into the infrastructure behind that boundary. Risks like misconfigured storage, over-permissive IAM roles, exposed workloads, and SaaS-to-SaaS OAuth grants live entirely outside the proxy's view.
Wiz fills this gap by bringing your cloud and SaaS context into a single connected system: the Wiz Security Graph. Instead of treating risks in isolation, the graph connects the dots. If DSPM finds an exposed S3 bucket containing sensitive data, the graph maps exactly which identities can reach it and uses CIEM to flag over-permissioned access. You get a single, prioritized attack path rather than a flood of disconnected alerts.
Wiz also actively teams up with your existing CASB and SSE platforms via the Wiz Integration Network (WIN). With the Netskope integration, Wiz can trigger a webhook when it detects a high-severity issue, prompting Netskope to automatically restrict access or block network addresses—no human intervention required. Integrations like Zscaler Avalor and Cato Networks pull Wiz vulnerabilities and posture data directly into their dashboards. This allows analysts to investigate inside-out cloud risks and outside-in network alerts from one unified console.
Want to see how infrastructure visibility and network enforcement work together? Request a free Wiz demo today to explore the platform.
See your cloud security architecture in action
Wiz maps your entire cloud environment and surfaces the attack paths that put your organization at risk.
