When SaaS integrations become a blind spot

The Salesloft incident was a reminder that the connections between SaaS platforms are often the weakest link in an organization's security posture. When a third-party marketplace app is compromised, data owners have few options for detecting the breach or cutting off access quickly. The attack surface only grows as more integrations are added, and security teams are left without visibility into who is accessing their data or how it is flowing between platforms.

Cloudflare is prototyping a set of solutions that route SaaS-to-SaaS traffic through a single proxy, giving data owners and SaaS providers a control point for monitoring, anomaly detection, and credential management. The goal is to make this capability available broadly, and the company is seeking feedback from both data owners and SaaS platform providers during development.

Two approaches to proxying SaaS traffic

Cloudflare is exploring two deployment patterns for intercepting and securing traffic between SaaS applications and their marketplace integrations. Both rely on proxying L7 traffic, but they differ in where the proxy sits and who controls it.

Control at the customer's domain

Because Cloudflare can proxy any hostname under a customer's control, a data owner like Acme Corp. can route traffic to a SaaS provider through a custom domain such as saas.acme.com instead of acme.saas.com. This puts Cloudflare's reverse proxy in front of the SaaS vendor, making it the only entity with programmatic access to the provider's APIs. Token swapping and key splitting can then be applied transparently to any integration.

One caveat: authorization flows often bypass vanity hostnames. OAuth callbacks typically hit URLs like oauth.saas.com, so marketplace apps must support branded URLs for their auth flows (oauth.saas.acme.com) for this setup to work.

With the proxy in place, a data owner would have been able to respond to a breach like the Salesloft incident by:

  • Seeing which entities can access data and where requests originate, using existing analytics and filtering tools for traffic sources, IPs, and user agents.
  • Shutting off access immediately at the proxy level, without rotating credentials on the SaaS platform.
  • Detecting anomalies by comparing traffic patterns against baselines, such as a sudden shift in data exfiltration flows.

Protection at the SaaS provider

The second approach is aimed at SaaS platforms themselves. This is a standard reverse proxy deployment, which Cloudflare can support with its existing Cloudflare for SaaS tooling. By proxying all traffic to the vendor, including API endpoints, the platform gains visibility into every SaaS-to-SaaS connection.

Cloudflare is building enhancements to API Shield for this scenario, with controls that include:

  • Token and session logging for OAuth tokens, providing audit trails.
  • Session anomaly detection that flags unusual behavior on a token or session.
  • Token replacement, where Cloudflare substitutes its own tokens for SaaS-generated ones, enabling fast rotation and lockdown.

SaaS vendors can then expose some of these capabilities to their end customers through their own dashboards.

Splitting keys to avoid storing secrets

Both approaches depend on controlling access without holding complete credentials. Storing full bearer tokens would add a significant security burden, so Cloudflare uses key splitting instead.

A bearer token is divided into two fragments, Part A and Part B, that are mathematically interdependent. Part A is given to the fourth-party integration, such as Drift or Zapier, and Part B is stored in Cloudflare's edge. On its own, Part A is random noise that will not authenticate to any SaaS platform; neither fragment is usable alone.

This creates a control point that cannot be bypassed. The integration must present Part A to Cloudflare's edge, where Part B is retrieved, the token is reconstructed in memory for microseconds, the request is forwarded, and the token is cleared. The full token never exists in a database or log.

The approach changes incident response. Deleting Part B revokes access instantly, without rotating credentials on the SaaS platform. And if an attacker compromises the integration or Cloudflare's storage, they only obtain a fragment that is worthless on its own. Security teams also gain a complete audit trail of every API call made by an integration.

Next steps

Cloudflare is building toward early access for this work and is inviting both data owners and SaaS vendors to participate. Data owners concerned about SaaS-to-SaaS risk can sign up for early access, and SaaS providers interested in better API security tooling for third-party integrations can provide feedback through the same channel.