On August 31, 2025, Zscaler confirmed a data breach that didn’t involve a broken firewall, zero-day vulnerability, or compromised endpoint. Instead, the attackers went after something far more subtle—and in many environments, far more dangerous: OAuth tokens from a SaaS integration.
Zscaler Data Breach
The breach exposed customer data from Zscaler’s Salesforce environment and was part of a larger campaign affecting over 700 organizations. The entry point? Stolen OAuth tokens from a connection between Salesforce and Salesloft Drift.
If you’re a developer, DevOps engineer, or anyone building cloud-native applications, this incident should stop you in your tracks.
Here’s why.
*OAuth: The Double-Edged Sword of Modern Integrations
*
OAuth is brilliant. It allows delegated access between applications without handing over passwords. But that convenience comes at a cost.
When not implemented carefully—or worse, when tokens are left active indefinitely—OAuth becomes an unmonitored backdoor into your systems. Once a token is stolen, an attacker doesn’t need MFA. They don’t need passwords. They just need the token.
This is exactly what happened in the Zscaler case.
*TL;DR of the Breach
*
What happened? Hackers (UNC6395) used stolen OAuth tokens to access Salesforce instances via Salesloft Drift integrations.
When? Between August 8 and 18, 2025.
How? They bypassed MFA, used automated scripts, and exfiltrated customer data.
Who was affected? Over 700 organizations, including Zscaler.
What was exposed? Contact data, job titles, email addresses, phone numbers, licensing info, and Salesforce support case text (no passwords or financials).
Why does this matter? OAuth-based access was abused at scale, bypassing traditional security protocols.
*Why This Breach Should Worry Developers and Engineers
*
We’re now living in an era where backend security alone isn’t enough. Application-to-application connections—especially through third-party services—are becoming the preferred attack vector. And developers play a huge role in how these integrations are built and maintained.
*Some real concerns:
*
- Tokens don’t expire unless revoked.
- Scopes are often too broad (e.g., full_access instead of just read_contacts).
- Revocation flows are rarely automated.
- Audit logs for token-based access are inconsistent or absent.
- Developers may treat integrations as "fire and forget."
In the Zscaler breach, it wasn’t just bad luck. It was a symptom of how the entire SaaS ecosystem handles trust and access.
Anatomy of the Zscaler Breach: Technical Breakdown
The attackers used OAuth tokens stolen from Salesloft Drift integrations. These tokens had access to Salesforce data. Once inside, the attackers:
*Bypassed Multi-Factor Authentication (MFA) using the tokens
*
Automated the attack using Python scripts, enabling mass data theft across hundreds of orgs
Exfiltrated metadata and plaintext from Salesforce support cases
No brute force was necessary. No zero-day was involved. This was credential-based access abuse on a massive scale.
The Risk Pattern We’re Seeing Across the Industry
Common thread: Attackers didn’t need to hack into the system—they used access that was already granted.
Developer Mistakes That Often Go Unnoticed
The reality is: devs don’t always consider OAuth an active security risk.
Some common missteps include:
Storing tokens insecurely (e.g., in .env files committed to Git, browser localStorage)
Hardcoding credentials for integrations
Not implementing token revocation workflows
Skipping least-privilege scopes for speed or simplicity
Lack of auditing for third-party API activity
If your app integrates with Salesforce, Slack, Google Workspace, or any other major SaaS, these oversights could be fatal.
Zero Trust Can’t Stop What You Don’t Monitor
Zscaler is a pioneer of Zero Trust security. Ironically, their breach shows that Zero Trust doesn't work if your third-party apps are implicitly trusted.
OAuth tokens introduce a layer of trust between services, but that trust is often permanent. There’s no re-verification of the user or device once the token is issued. Unless specifically revoked or rotated, it provides long-lived access.
In other words, the “Trust nothing, verify everything” mantra only applies if you're actually doing the verifying.
What Should Developers Be Doing Differently?
If you’re involved in API integration, DevOps, SaaS deployments, or backend architecture, you’re in the security game whether you like it or not.
Here’s what needs to change:
- Audit All OAuth Integrations Regularly
Go through every third-party connection your app uses. Ask:
Is this still needed?
Does it need full access?
When was the token last rotated?
- Limit Scopes Aggressively
Don’t request more permissions than necessary. If the app only needs to read contact data, don’t ask for write or admin access.
- Set Up Token Expiration Policies
Many APIs support token lifetimes. Use short-lived tokens and require refresh flows with re-authentication when possible.
- Monitor API Usage for Anomalies
Build or use tools that flag unusual data exports or access patterns. Look for:
New devices or IPs accessing APIs
High-volume downloads
Access outside business hours
- Use Secrets Management
Never store OAuth tokens in code or config files pushed to Git. Use environment secrets, encrypted vaults, or secure key stores.
- Build Token Revocation Flows
Make it easy for users (or your security team) to revoke access to third-party apps at any time.
For DevOps and SecOps Teams: Expand Your Monitoring Scope
It’s not enough to monitor infrastructure. You need visibility into:
OAuth token issuance and usage
Third-party app behavior inside core platforms
Cross-platform data movement via APIs
Access logs from connected SaaS platforms
If your SIEM or security tools don’t include OAuth-related activity, your blind spot is bigger than you think.
What This Means for the Future of SaaS Security
The Zscaler breach will likely push forward new security standards across the industry, especially around:
OAuth token hygiene and expiration
Vendor due diligence for SaaS integrations
Mandatory breach reporting for third-party services
Continuous authorization (vs. one-time authentication)
Expect to see more regulations that hold both SaaS vendors and their customers accountable. Shared responsibility is becoming a legal reality, not just a security best practice.
What If You're Building a SaaS Product?
This breach is a great reminder that your users trust you not just with their data—but with the services you connect them to.
Here are some immediate steps to take:
Implement strict token lifecycle management
Log and expose token access history to users
Provide revocation and permission audit interfaces
Educate customers about OAuth risks and best practices
Build internal playbooks for token-based attack scenarios
Don’t treat integrations as an afterthought. They are part of your threat surface.
Personal Reflections as a Developer
I’ve worked on integrations with Salesforce, Google APIs, and internal CRMs. And I’ll admit it: I’ve reused tokens. I’ve granted full access “just to make it work.” I’ve written scripts that silently pull data for reporting dashboards without much thought to security.
This breach made me rethink all of that.
We’re at a point where developer decisions have direct consequences for security. You don’t have to be building a firewall or encryption module to play a role. Your OAuth config, your scopes, your refresh logic—all of it matters.
We have to start treating security as part of development, not something bolted on afterward.
Final Thoughts: Secure the Invisible
The most dangerous breaches are the ones you don’t see coming. Zscaler didn’t fall to malware or ransomware—they fell to trust.
As developers and engineers, we must learn to secure the invisible: tokens, APIs, integrations, background processes. These are the weak spots that attackers are targeting.
So, the next time you implement an integration, ask yourself:
What’s the minimum access this needs?
What happens if this token leaks?
Will anyone notice if it’s abused?
Because someone out there is asking those questions—for the wrong reasons.
Top comments (0)