Connected App, Connected Risk: Lessons from the Salesforce–Drift Breach

One weak app integration exposed some of the world’s biggest companies — including Cloudflare, Palo Alto Networks, and Zscaler — to data theft.

At first glance, this incident looked like yet another Salesforce or Google Workspace hack. Headlines shouted that billions of Gmail accounts were at risk. But that wasn’t the real story. The breach actually came through a connected app—Drift, an AI-powered chatbot — which attackers used as a back door into customer data.

This case shows how a single integration can ripple through an entire enterprise ecosystem. For CISOs and IT leaders, the Salesforce–Drift breach is a stark reminder that supply chain attacks are no longer limited to hardware or software vendors. Now, connected apps themselves are part of the supply chain—and they need just as much scrutiny.

What Is an OAuth Token?

At the heart of this breach was something called an OAuth token. If you’ve never heard the term, think of it like a spare key. When you connect an app to Salesforce, Google Workspace, or another SaaS platform, that app needs a way to “let itself in” without asking for your username, password, and MFA every single time. Instead of handing over your house keys, you give the app a special key—the OAuth token—that works only for that door.

The upside: it’s more convenient and usually safer than sharing passwords. The downside: if attackers steal the token, they now have the same access as the app, bypassing your MFA protections and behaving like a trusted insider. That’s exactly what happened here — Drift’s insecure token handling became a skeleton key for attackers to raid Salesforce and Google Workspace data.

What Really Happened

Attackers didn’t breach Salesforce itself — they exploited the way Drift integrated with Salesforce through middleware provider Salesloft. This insecure setup allowed them to generate OAuth tokens on Drift’s behalf. With those tokens in hand, attackers gained access to Salesforce environments and customer data without needing usernames, passwords, or MFA.

“Hackers are targeting keys. They’re targeting tokens. They know that often these are back doors into your infrastructure,” Sherri Davidoff, founder of LMG Security, explained on a recent Cyberside Chats episode.

The impact was broad. Cloudflare disclosed it had to rotate 104 compromised tokens. Zscaler confirmed attackers accessed customer service case data. Even Google Workspace customers were affected, though early media reports exaggerated the severity. This wasn’t a direct hack of Salesforce or Google; it was a supply chain OAuth compromise.

Why This Matters

Customer relationship data may not seem as sensitive as credit cards or health records, but it can be even more dangerous in the wrong hands. Service tickets, order histories, and case notes give attackers exactly what they need to impersonate trusted vendors and craft targeted phishing campaigns.

“This isn’t health information or credit cards, but it creates a really accurate profile. And with that profile, we can spear phish someone very, very efficiently,” shared Matt Durrin, Director of Research and Training for LMG Security.

Imagine receiving an email that references your exact service call date and ticket number. That level of detail makes scams much harder to detect—and much more effective.

Key IoT Security Parallels

Interestingly, the Salesforce–Drift incident mirrors some familiar IoT security challenges:

• Devices or apps often get more access than they need.
• Keys or credentials are sometimes hardcoded or poorly managed.
• Monitoring often lags behind the pace of adoption.

Just as insecure IoT devices have become gateways for attackers, SaaS integrations can quietly become the weak link in your enterprise security chain.

How to Protect Your Organization

The Salesforce–Drift breach underscores the importance of tightening SaaS security. Here are five critical steps:

1. Demand Vendor Security Testing

Don’t just trust that your SaaS providers are secure—make them prove it. Require third- and fourth-party providers to undergo penetration testing and provide attestation letters or summaries of findings. An experienced testing team may have identified Drift’s flawed token issuance before attackers did. While it’s not realistic to test every single app in your supply chain, you can focus on those that connect to high-value platforms like Salesforce, M365, or Google Workspace. Over time, build vendor security testing into procurement and renewal contracts so it becomes part of your organization’s standard due diligence.

See LMG’s blog on third-party risk management for a deeper dive.

2. Enforce Least-Privilege Permissions

Many apps are over-provisioned at setup—they’re given blanket access to entire datasets because it’s faster and easier for developers or administrators. That convenience is costly when attackers exploit the extra access. Treat connected apps like individual users: review what objects and fields they actually need, and revoke everything else. For example, a chatbot may require access to customer names and contact information, but doesn’t need financial records or HR data. Regular quarterly audits of app permissions should be part of your broader cloud security review process.

3. Rotate Keys Regularly

OAuth tokens and API keys should be treated like passwords — and rotated on a regular schedule. Industry leaders like AWS recommend rotation every 60–90 days, and many cloud platforms provide automated tools to manage the process. If automation isn’t available, create a manual rotation calendar and assign responsibility to a specific team. The reason is simple: long-lived keys are much more likely to be exposed, whether through code repositories, logs, or accidental sharing. Shortening their lifespan dramatically reduces the window of opportunity for attackers.

4. Monitor for Data Exfiltration

Traditional monitoring focused on on-premise systems, but today’s attackers know the crown jewels often live in SaaS platforms. Configure your SIEM, CASB, or cloud-native tools to watch for red flags: unusual query patterns, large Bulk API jobs, or traffic sent to unapproved destinations. For example, if a third-party app suddenly requests thousands of customer service records at 2 a.m., that should trigger an alert. Even better, use egress controls to restrict where data can go—such as approved IP addresses or managed storage locations—so that even if an attacker gets in, exfiltrating large amounts of data becomes much harder.

5. Add SaaS to Your Incident Response Plan

Most incident response playbooks still focus on compromised accounts or malware infections, but SaaS incidents require different actions. If a connected app is compromised, your team must know how to revoke or reissue OAuth tokens quickly, and how to communicate with both vendors and internal stakeholders about the scope of impact. Practice this in tabletop exercises so your responders are comfortable with the mechanics. Adding a “SaaS chapter” to your incident response plan will ensure that when the next Drift-style compromise occurs, you’re not scrambling to figure out which buttons to push.

Next Steps

The Salesforce–Drift breach isn’t just a one-off event—it’s a glimpse of the future. As organizations adopt more SaaS tools and AI-driven integrations, attackers will continue to look for the weakest link in those chains. Every connected app is a potential entry point, and the only way to stay ahead is by treating integrations with the same rigor you apply to core systems.

At LMG Security, we help organizations strengthen their defenses through penetration testing, incident response planning, and security training. If you want to ensure your connected apps don’t become your weakest link, reach out to our team.