More than 700 organizations had Salesforce data stolen in August 2025 without a single password being cracked or a login page being touched. Attackers abused OAuth tokens issued to a connected application, the Salesloft Drift chatbot, and quietly queried customer data through a trust relationship the platform had already approved (FINRA, Cybersecurity Alert: Salesloft Drift AI Supply Chain Attack). That is the SaaS OAuth and connected-app attack surface in one sentence: valid tokens doing over-permissioned things, standing consent grants that never expire, and third-party apps that can pull your data even when your core platform is never breached.
This guide is written for the person who has to scope the work: the security lead running dozens of SaaS-to-SaaS integrations who needs to turn "test our OAuth and connected-app exposure" into a statement of work that testers can execute and auditors can trust. You will get a direct answer to how this is tested, a connected-app inventory to hand your testers, a SOW-ready scoping checklist, the delegated-trust attack surface it covers, and the boundary that keeps the engagement authorized.
TL;DR
What it is: A SaaS OAuth and connected app penetration test assesses delegated trust, the tokens and consent grants that let third-party apps act inside your SaaS on your behalf. It is not the same as a leaked-credential or secrets-sprawl test.
Lead with a checklist: Scope eight things explicitly: connected app inventory, token scope review, consent grant hygiene, revocation drills, blast radius testing, guest and external access, admin consent workflow, and detection of anomalous token use.
The core risk: An over-scoped token or a compromised integration can read and export your data through the API, bypassing the login page and MFA, because the platform already trusts the connection.
Prove the blast radius: A credible test does not just list connected apps. It shows what a given app's token can actually reach, and what a revocation actually stops.
Why now: The Salesloft Drift breach (August 2025) and the Gainsight-Salesforce disclosure (November 2025) both abused connected-app OAuth trust, and Microsoft published dedicated defender guidance on the pattern in July 2026.
How do you penetration test SaaS OAuth integrations and connected apps?
You test SaaS OAuth integrations and connected apps by inventorying every third-party app that holds an OAuth grant into your platform, reviewing the scopes and permissions each token actually carries, and then proving what those tokens can reach through the API rather than through the login screen. The engagement confirms whether over-scoped or stale grants let an app read or export data beyond its stated purpose, whether a compromised integration could be used to pull data while bypassing MFA (as happened in the Salesloft Drift breach), whether revoking a grant genuinely severs access, and whether your monitoring would detect anomalous token use. To prevent a Salesloft Drift style token-abuse breach, the test focuses on the trust itself: the standing consent grants and long-lived tokens that a platform honors automatically, without a fresh authentication or a policy check.
This is a delegated-trust engagement. The interesting findings are not broken login flows. They are legitimate-looking connections that carry far more access than anyone remembers granting, tokens that never expire, and consent that a single user approved for the whole tenant.
SaaS OAuth testing is not leaked-secrets testing
It is worth drawing a hard line here, because these two engagements are often confused and they cover different risks. Leaked-secrets testing is about credentials that escaped: a hardcoded API key in a public repository, a token in a config file, a secret in an infostealer log. The credential was never supposed to be visible, and the fix is to find it, rotate it, and stop it leaking again. We cover that side in depth in our write-up on non-human identity attacks and leaked API keys.
SaaS OAuth and connected-app testing is the opposite problem. Nothing leaked. The token is exactly where it is supposed to be, held by a connected app you deliberately authorized. The risk is that the grant is over-scoped, that it is standing rather than short-lived, that it survives long after the integration's usefulness, and that if the third party is compromised, the attacker inherits a credential your platform already trusts. In the Salesloft Drift and Gainsight incidents, no secret leaked from the victim organizations. The attackers abused OAuth tokens that were working exactly as designed. That is why this scope is defined by delegated trust, not by exposure, and why it needs its own statement of work.
The connected-app inventory to hand your testers
Good scoping starts with a good inventory, and connected apps are notoriously under-inventoried because any user with consent rights can add one. Before the test begins, build a written inventory of the delegated trust across your SaaS estate so testers know exactly what they are assessing.
Hand your testers an inventory that covers, at minimum:
Inventory item | What to record | Why it matters |
|---|---|---|
Connected and third-party apps | Every OAuth app, integration, and marketplace add-on granted access to each SaaS platform | This is the real attack surface, and it is usually larger than anyone expects |
Granted scopes and permissions | The OAuth scopes, API permissions, and object-level access each app holds | Over-scoped grants are the single most common finding; a chatbot rarely needs full data-export rights |
Token type and lifetime | Access tokens, refresh tokens, and whether grants are standing or short-lived | Long-lived and refreshable tokens are what let a breach persist for months |
Consent record | Who approved each grant, whether it was user consent or admin consent, and when | Tenant-wide admin consent from one approval is a high-impact, low-visibility risk |
Owner and business justification | The internal owner and the reason each integration exists | Orphaned apps with no owner are prime candidates for revocation |
Guest and external access | External users, partner tenants, and cross-org sharing tied to each integration | Weak guest configurations widen the blast radius of any single grant |
Two inventory items deserve extra attention when scoping. First, marketplace and vendor integrations (the AppExchange-style add-ons) concentrate risk, because a single compromised vendor can reach every customer that installed its app, which is precisely the pattern the Salesloft Drift and Gainsight incidents followed. Second, machine-to-machine integrations and agent connectors often request broad scopes by default. If your estate leans on automation platforms or AI agents, name those grants explicitly in scope. The security of the connectors themselves, such as an MCP server bridging an AI assistant to your data, is a related engagement covered in our MCP server security assessment guide.
The SOW-ready scoping checklist
A connected-app test is judged on whether it proves what your delegated trust can actually do, not on whether it lists your integrations. Write these eight items into the statement of work so the engagement reaches the trust itself, not just the app catalog.
Connected app inventory. Enumerate every OAuth app and integration with a grant into each platform, and reconcile the live list against what governance believes is installed. The gap between the two is often the finding.
Token scope review. For each grant, compare the scopes the app holds against the scopes its function requires. Flag every over-scoped token, especially data-export and admin-level scopes on apps that do not need them.
Consent grant hygiene. Identify stale, orphaned, and duplicate grants, apps with no owner, and integrations that outlived the project that installed them. Standing consent that no one remembers approving is a live door.
Revocation drills. Prove that revoking a grant actually severs access. Confirm that access and refresh tokens are invalidated, that cached sessions do not survive, and that the app cannot silently re-consent.
Blast radius testing. For a representative over-scoped grant, demonstrate what its token can actually reach through the API: which objects, records, and exports become available. This turns an abstract permission into a concrete impact statement.
Guest and external access misconfigurations. Test how external users, partner tenants, and cross-org sharing interact with connected apps, since weak guest configurations were one of the paths in the 2025 to 2026 campaigns.
Admin consent workflow review. Assess who can approve tenant-wide consent, whether admin consent is required for sensitive scopes, and whether a single user approval can grant an app access across the whole tenant.
Detection of anomalous token use. Validate that your monitoring would notice a connected app suddenly running bulk queries or exporting data at an unusual volume, the behavioral signal that the Salesloft Drift activity generated.
Scoping these eight items is what separates a real delegated-trust engagement from an OAuth configuration checklist. The same attack-path thinking applied provider-agnostically to cloud roles and cross-account trust is covered in our cloud IAM penetration testing guide, and the general mechanics of turning a fuzzy request into a testable scope are in how to scope a penetration test.
The OAuth and connected-app attack surface
The reason this scope exists is that a connected-app compromise does not look like an intrusion. There is no failed-login spike, no MFA prompt, and no malware on your platform. The attacker uses a token the platform already honors, and the traffic looks like the integration doing its job.
The delegated-trust path runs like this. Your SaaS platform issues an OAuth token to a connected app when a user or admin grants consent. That token carries whatever scopes were approved, and it typically persists as a refreshable, standing credential. If the third party that holds the token is compromised, or if the grant was over-scoped to begin with, the token can be used to call your platform's API directly, reading and exporting data with the granted scopes. Because the platform is authenticating a trusted connection rather than a user, the login page and MFA are simply not in the path. Your core platform is never breached in the way a defender expects, yet your data leaves through the front door you built for the integration.
Testing this surface means following the trust, not the perimeter. A credible engagement demonstrates which grants are over-scoped, what those grants can reach, and where a control (least-privilege scopes, short-lived tokens, admin consent, revocation, and anomaly detection) would have interrupted the path. The scope boundary is the same one that governs any authorized test: you assess the platforms, tenants, and integrations your organization owns and controls, using test and sandbox connections where a production action would be disruptive, and you do not touch other tenants or the SaaS vendor's shared infrastructure. The provider-specific rules of engagement that formalize this are covered in our guide to cloud penetration testing rules of engagement across AWS, Azure, and GCP.
Why this belongs in scope: three disclosures, defender-framed
Recent disclosures make the case better than any threat model, and they all point at the same control gaps rather than any single exploitable bug.
The canonical case is the Salesloft Drift breach. Between roughly August 8 and August 18, 2025, the activity cluster that Google Threat Intelligence Group tracks as UNC6395 abused OAuth tokens tied to the Salesloft Drift chatbot to access Salesforce environments across a large number of organizations, running targeted queries to export data and searching it for further secrets such as cloud access keys (Google Threat Intelligence Group). FINRA later put the reach at more than 700 organizations and told firms to disconnect the affected integrations and rotate exposed credentials (FINRA). No password was cracked; the abused credential was a connected app's token.
The pattern then recurred. In November 2025, Salesforce disclosed unauthorized access to some customers' data through Gainsight-published connected apps, again via OAuth token misuse rather than any platform vulnerability, and revoked the associated tokens while it investigated (Cybersecurity Dive reporting on the Salesforce advisory). A different connected app, the same delegated-trust weakness.
Microsoft made the pattern official in July 2026. Its guidance on defending SaaS applications against ShinyHunters OAuth abuse maps three intrusion paths (consent-phishing of malicious OAuth apps, and the supply-chain compromises via Salesloft and Gainsight) and recommends governance controls including risk scoring for OAuth apps on a 0 to 100 scale, flagging apps that have been inactive for 90 days or more, surfacing apps with elevated OAuth scopes, and enabling event monitoring for connected-app activity (Microsoft Security Blog). None of this is a reason to panic, and the specific abused grants have been revoked. All of it is a durable reason to test delegated trust rather than assume it, which is exactly what a scoped connected-app engagement does.
What this means for defenders
Scope delegated trust as its own engagement. Do not fold connected-app testing into a generic web-app or leaked-secrets test. The findings that matter (over-scoped tokens, standing grants, tenant-wide consent) only surface when the trust relationship itself is the target.
Put revocation and blast radius in the statement of work. An inventory tells you what exists. A revocation drill and a blast-radius test tell you what an integration can actually do and whether you can stop it, which is what an auditor and an incident responder both need to know.
Name your marketplace and agent integrations explicitly. Vendor add-ons and AI-agent connectors concentrate supply-chain risk and often request broad scopes by default. If they are not named in scope, the test will not reach them.
Use the results as access-governance and vendor-risk evidence. A documented connected-app test gives your SOC 2 and ISO 27001 programs concrete evidence that third-party access paths were inventoried, scoped, and tested, which strengthens the vendor-risk and access-control sections of an audit.
Connected-app abuse and delegated-trust paths are business-context work: understanding why a given integration exists, what its access should be, and how an attacker would chain it is human pentester and red team work, not a scanner job. Stingrai (founded 2021) is a CREST-accredited penetration testing provider, and this scope maps naturally onto red teaming and adversary emulation or a scoped engagement delivered through PTaaS; our senior human pentesters own the SaaS OAuth and connected-app work end to end. For the web applications and APIs that sit in front of your SaaS estate, our autonomous agent Snipe hunts the complex authorization, IDOR, and business-logic flaws that generic scanners miss, complementing the human-led delegated-trust work; you can see how that fits in our web application penetration testing service. To scope an engagement, start with our services overview or pricing.
Frequently Asked Questions
How do you penetration test SaaS OAuth integrations and connected apps? You inventory every third-party app that holds an OAuth grant into your platform, review the scopes each token actually carries, and prove what those tokens can reach through the API rather than through the login screen. The test confirms whether over-scoped or stale grants let an app read or export data beyond its purpose, whether a compromised integration could pull data while bypassing MFA, whether revoking a grant genuinely severs access, and whether your monitoring would detect anomalous token use.
How is this different from leaked-secrets or non-human-identity testing? Leaked-secrets testing is about credentials that escaped, such as a hardcoded API key in a repository or a token in an infostealer log, where the fix is to find and rotate the exposed secret. SaaS OAuth testing is the opposite: nothing leaked, the token is held by an app you authorized, and the risk is that the grant is over-scoped, standing, or inheritable by an attacker who compromises the third party. They cover different risks and need different statements of work.
What should be in scope for a connected-app penetration test? Scope eight items: a connected app inventory, a token scope review, consent grant hygiene, revocation drills, blast radius testing, guest and external access misconfigurations, an admin consent workflow review, and detection of anomalous token use. Together these prove not just what integrations exist, but what their delegated trust can actually reach and whether you can revoke it.
What was the Salesloft Drift breach and how does it relate to OAuth? Between roughly August 8 and 18, 2025, an activity cluster tracked as UNC6395 abused OAuth tokens issued to the Salesloft Drift chatbot to access Salesforce data across a large number of organizations, exporting records and searching them for further secrets. FINRA reported the reach at more than 700 organizations. No password was stolen; the abused credential was a connected app's OAuth token, which is why it is the canonical connected-app case.
Can testing prevent a Salesloft Drift style token-abuse breach? Testing cannot stop a third-party vendor from being compromised, but it directly reduces your exposure to that compromise. By finding and shrinking over-scoped grants, retiring standing tokens, validating that revocation works, and confirming that anomalous bulk exports are detectable, a connected-app test removes the conditions that turn a vendor breach into your data breach.
What is delegated trust in a SaaS context? Delegated trust is the access you grant a third-party app to act inside your SaaS on your behalf, represented by an OAuth token with a set of scopes. Because the platform authenticates the trusted connection rather than a user, that token can reach your data through the API without a fresh login or an MFA prompt, which is what makes over-scoped and standing grants risky.
Who should perform a SaaS OAuth and connected-app test? This is human pentester and red team work, because the important findings depend on business context: why an integration exists, what its access should be, and how an attacker would chain it. Automated scanners can enumerate grants, but judging whether a grant is over-scoped and proving its blast radius requires a tester who understands the workflow behind the integration.
How does a connected-app test support SOC 2 or ISO 27001? A documented connected-app test gives auditors concrete evidence that your third-party access paths were inventoried, scoped, and tested, which supports the vendor-risk, access-control, and access-governance sections of SOC 2 and ISO 27001. The report becomes evidence your compliance program can hand to its auditors.
What did Microsoft recommend for defending against OAuth abuse? In July 2026, Microsoft published guidance on defending SaaS applications against ShinyHunters OAuth abuse. It recommends governance controls including risk scoring for OAuth apps on a 0 to 100 scale, flagging apps inactive for 90 days or more, surfacing apps that hold elevated OAuth scopes, and enabling event monitoring for connected-app activity, all of which map directly to what a connected-app penetration test validates.
References
Google Threat Intelligence Group. Widespread Data Theft Targets Salesforce Instances via Salesloft Drift. August 26, 2025. https://cloud.google.com/blog/topics/threat-intelligence/data-theft-salesforce-instances-via-salesloft-drift/. Primary advisory attributing the OAuth-token abuse campaign to UNC6395, covering the August 8 to 18, 2025 activity window and defensive recommendations to revoke tokens, apply least-privilege scopes, and enforce IP restrictions on connected apps.
FINRA. Cybersecurity Alert: Salesloft Drift AI Supply Chain Attack. 2025. https://www.finra.org/rules-guidance/guidance/salesloft-drift-AI-supply-chain-attack. Regulatory alert to member firms reporting more than 700 affected organizations and advising firms to disconnect affected integrations, rotate exposed credentials, and apply least-privilege principles to third-party applications.
Microsoft Security Blog. Defending SaaS-based Applications Against ShinyHunters OAuth Abuse. July 13, 2026. https://www.microsoft.com/en-us/security/blog/2026/07/13/defending-saas-based-applications-against-shinyhunters-oauth-abuse/. Defender guidance mapping three Salesforce intrusion paths and recommending OAuth risk scoring, detection of inactive and over-privileged apps, and connected-app event monitoring.
Cybersecurity Dive. Salesforce Investigating Campaign Targeting Customer Environments Connected to Gainsight App. November 2025. https://www.cybersecuritydive.com/news/salesforce-investigating-customer-connected-Gainsight/806093/. Reporting on Salesforce's November 2025 advisory that OAuth token misuse through Gainsight-published connected apps enabled unauthorized access, with Salesforce revoking the associated tokens.
OAuth 2.0 Authorization Framework. RFC 6749. https://datatracker.ietf.org/doc/html/rfc6749. The specification defining OAuth scopes, access tokens, and refresh tokens, the delegated-trust mechanics that a connected-app penetration test assesses.
OWASP. OAuth 2.0 Protocol Cheat Sheet. https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.html. Defensive reference for scope minimization, consent, and token handling in OAuth-based integrations.
