Background
The Salesforce breach occurred when attackers obtained OAuth tokens through trusted third-party integrations and social engineering, granting them legitimate API-level access without compromising Salesforce itself. Utilizing these tokens, they executed API calls and broad Salesforce Object Query Language (SOQL) queries to enumerate objects and extract large volumes of Customer Relationship Management (CRM) data—including contacts, accounts, and case notes—from multiple customer tenants. In some instances, they also searched for additional credentials like AWS and Snowflake keys to facilitate lateral movement or enable further monetization through extortion and targeted phishing, ultimately impacting hundreds of organizations and billions of records.
In response, Salesforce and Salesloft revoked all active OAuth tokens linked to the Drift app and removed the app from AppExchange. Salesforce has also enhanced monitoring for unusual API activity and is working with affected organizations to secure environments and mitigate risks.
Beyond Authentication: The Real Key to Mitigation
While the Salesforce breach highlights the dangers of stolen OAuth tokens, preventing similar attacks involves more than just strengthening authentication. Organizations often focus on measures such as rotating OAuth tokens and credentials, enforcing strong MFA, shortening token lifespans, and monitoring for unusual API activity. These safeguards are important, but they only address part of the problem.
The deeper issue lies in what a token—or the associated user role—is actually authorized to access and what operations it can perform. This concern goes beyond technical controls and into the business context, which naturally varies between organizations. Even with strict authentication policies in place, a compromised token—whether obtained via phishing, social engineering, or a misconfigured third-party app—still provides attackers with a limited window of access. The key question, therefore, is not just whether a token can be stolen, but what an attacker can do with it once they have it.
Review Your Token Scope Regularly
Applying the principle of least privilege is essential, but it’s not enough to set token scopes once and forget about them. Tokens should be reviewed regularly—not only for who owns them, but also for what endpoints, operations, and roles they can access. By carefully limiting token scope, organizations can minimize the blast radius if a token is ever compromised.
From the API Call Perspective
- Broken Authentication: If a user with a token can access data, but the same endpoint is accessible even without a token, this indicates a broken authentication issue.
- Broken Object Level Authorization (BOLA): If Customer A can access data belonging to Customer B, authorization is missing or misapplied.
- Broken Object Property Level Authorization (BOPLA): If User A can view object fields they shouldn’t—horizontally (other users’ data) or vertically (admin-only fields)—it represents a property-level flaw.
- Broken Function Level Authorization (BFLA): If a user or integration can perform operations outside their role—such as a third-party Salesforce integration token executing unrestricted SOQL queries—this is a function-level authorization failure.
From the Business Logic Perspective
Securing tokens also requires understanding how they are used within workflows:
- Privilege Escalation Risks: Attackers may start with a low-privilege token and exploit vulnerabilities to escalate to admin-level access. Here, the token itself isn’t the problem—it’s the business logic that enables the escalation.
- Third-Party & LLM Integrations: Integration tokens often have broad access. With the growing use of LLMs and AI agents, data can be exposed indirectly through AI query interfaces—even without direct token misuse.
- Supply Chain Trust: Tokens granted to third-party integrations must be reviewed regularly. Check for reported CVEs affecting connected apps, validate the data they can access, and limit integrations that show signs of compromise.
Reviewing token scopes should go beyond technical hygiene—it’s about aligning access design with business needs and continuously monitoring both direct API permissions and indirect access paths. By doing so, even if attackers obtain a token, the damage they can inflict is sharply constrained.
Strengthening Your API and Token Security Today
Understanding and reviewing token scope is only part of the equation—organizations also need a proactive, comprehensive approach to securing their APIs. To prevent attacks like the Salesforce breach, it’s critical to assess your API implementations and overall security posture before attackers do. Waiting until after a compromise is too late; early evaluation is key to minimizing risk.
RidgeBot API Security Testing provides a practical solution. It helps organizations identify and safely exploit potential API vulnerabilities in a controlled environment. RidgeBot supports both black-box testing, where no credentials are provided, and gray-box testing, simulating an attacker with partial authenticated access. By evaluating both the scope of individual tokens and the business logic governing API workflows, RidgeBot provides comprehensive coverage of potential risks. It detects web vulnerabilities, uncovers flaws in business logic, and continuously tests API behavior to help ensure that even if a token is compromised, its potential misuse is sharply limited.
