The biggest SaaS security risks sit in the customer's half of the shared responsibility model: who can sign in, which apps hold tokens, what is shared and what is logged, and none of them stay fixed after go-live. The 2024 Snowflake campaign and the 2025 Salesloft Drift token theft did not break a platform; they used valid passwords and valid OAuth grants that nobody had reviewed. This list ranks ten SaaS security threats by our judgement of likelihood and impact across a typical estate of a few hundred apps, shows the ATT&CK v20 technique behind each one, and gives the first fix plus the signal to watch. It closes with a practical way to score, tier and correlate SaaS risk so the list becomes a working register. It is written for security architects, SaaS platform owners and identity teams; for the wider programme see the SaaS Security Guide.
The Top 10 at a glance
- Stolen credentials and sign-in that bypasses SSO and MFA
- Over-scoped third-party integrations and OAuth tokens
- Consent phishing and malicious app authorisation
- Identity sprawl and excessive admin rights
- Shadow SaaS and unmanaged tenants
- Misconfiguration, drift and risk creep
- Over-sharing and uncontrolled external access
- Session and token theft after sign-in
- Logging gaps and licence-tier blind spots
- Cross-SaaS blast radius: secrets in SaaS data and chained tenants
| # | Risk | How attackers use it (ATT&CK v20) | First fix | Signal to watch |
|---|---|---|---|---|
| 1 | Credentials and weak sign-in | Log in with infostealer or sprayed passwords (T1078.004, T1110.003, T1110.004) | SSO only, phishing-resistant MFA, local login disabled | Local or legacy sign-in on an SSO-enforced app |
| 2 | Over-scoped integrations | Replay a supplier's OAuth refresh token (T1528, T1199) | Minimum scopes, IP restriction, token inventory | Integration token used from an unexpected network |
| 3 | Consent phishing | Trick a user into approving an attacker's app (T1671, T1566) | Admin consent workflow, verified publishers only | New app grant with broad scopes |
| 4 | Identity sprawl | Grant an extra admin role to keep access (T1098.003) | Fewer super admins, JIT elevation | New admin or permission set assignment |
| 5 | Shadow SaaS | Abuse a forgotten app nobody monitors (T1078.004, T1528) | Discovery from IdP, OAuth grants, finance and network | Grants to apps not in the register |
| 6 | Drift and risk creep | Use settings loosened since the last review | Baseline scan with diff and exception expiry | High-severity control flips from pass to fail |
| 7 | Over-sharing | Read data from open links and shared stores (T1530) | Default sharing to specific people, link expiry | Anyone links created on tier 1 data |
| 8 | Session theft | Replay a stolen session cookie (T1539, T1550.004) | Short sessions, device and network binding | Same session from two networks |
| 9 | Logging gaps | Act where no audit trail is kept or read | Licence the logs, stream to the SIEM | Apps with no log feed in the last 24 hours |
| 10 | Cross-SaaS blast radius | Bulk export, then mine the data for keys (T1213.004, T1567) | Secret scanning of SaaS records, bulk export limits | Query volume spikes on integration users |
1. Stolen credentials and sign-in that bypasses SSO and MFA
The risk: SaaS accounts that still accept a username and password, either because the app was never connected to the identity provider, because local login stayed enabled after SSO, or because legacy protocols and device code flows skip conditional access. Attackers buy infostealer logs or spray common passwords (T1078.004 Cloud Accounts, T1110.003 Password Spraying, T1110.004 Credential Stuffing).
Why it matters: in the Snowflake breach, Mandiant reported that affected accounts "were not configured with multi-factor authentication enabled", that stolen credentials "had not been rotated for as long as four years", and that the instances had no network allow lists. About 165 organisations were notified.
The fix: enforce SSO and then remove the back door by disabling local passwords except for one or two monitored break-glass accounts per tier 1 app. Apply CISA SCuBA MS.AAD.1.1v1 ("Legacy authentication SHALL be blocked."), MS.AAD.3.1v1 ("Phishing-resistant MFA SHALL be enforced for all users.") and MS.AAD.3.9v1, which says device code authentication "SHOULD be blocked". For apps with their own login, enforce the app's MFA and add network allow lists for crown-jewel data platforms. See the Snowflake Security Guide and the MFA Guide.
2. Over-scoped third-party integrations and OAuth tokens
The risk: marketing, sales, support and AI tools connected to CRM, email and file stores with full or offline access scopes, long-lived refresh tokens and no IP restriction. The tokens live in the supplier's platform, so a breach there becomes your breach (T1528 Steal Application Access Token, T1199 Trusted Relationship). This is the core of third-party SaaS risk: you inherit the security of every integration you approve.
Why it matters: in the Salesloft Drift breach, Google Threat Intelligence Group says UNC6395 used Drift's OAuth access and refresh tokens from 8 to at least 18 August 2025 to query Cases, Accounts, Users and Opportunities in customers' Salesforce tenants. The Gainsight breach and the Klue OAuth breach repeated the pattern through other integrations.
The fix: keep an inventory of every integration with its owner, scopes, token type and last use. GTIG's advice after Drift is specific: "avoid overly permissive scopes like full access", set the connected app's "IP Relaxation" policy to "Enforce IP restrictions", and remove "API Enabled" from profiles in favour of a permission set. Give each integration its own integration user with read access to named objects only, and keep a runbook to revoke every token from one supplier within an hour. See the SaaS and OAuth App Governance Guide and the Salesforce Security Guide.
3. Consent phishing and malicious app authorisation
The risk: users are tricked, by email or by a phone call, into approving an attacker-controlled app, which then holds a token that survives password resets and MFA changes (T1671 Cloud Application Integration, T1566 Phishing).
Why it matters: in the ShinyHunters Salesforce campaign, GTIG describes callers posing as IT support who guided victims "to approve a version of the Data Loader app with a name or branding that differs from the legitimate version", then exported data at scale. In the Microsoft Midnight Blizzard breach, an OAuth app in a forgotten test tenant opened executive mailboxes.
The fix: in Entra ID apply SCuBA MS.AAD.5.1v1 ("Only administrators SHALL be allowed to register applications."), MS.AAD.5.2v1 (restrict user consent) and MS.AAD.5.3v1 (admin consent workflow). Microsoft recommends allowing user consent "only for applications that have been published by a verified publisher", and notes that changing the setting leaves existing grants unchanged, so review those separately. In Salesforce, limit "Customize Application" and "Manage Connected Apps" to a few administrators and allow-list approved connected apps. See the Entra ID Applications and Consent Guide.
4. Identity sprawl and excessive admin rights
The risk: each app has its own admin roles, local accounts, API users and permission sets, so admin rights multiply outside the identity provider's view. Leavers keep local accounts, integration users hold system administrator profiles, and attackers add roles to keep access (T1098.003 Additional Cloud Roles).
Why it matters: one admin account in a tier 1 app usually means every record, every connected app and the audit settings. NIST SP 800-210 says it is "crucial to design a flexible or real-time mechanism for assigning and revoking privileges" in SaaS, and the NCSC states that "user accounts on the service should be suspended when no longer required".
The fix: count super admins per app (SCuBA allows two to eight Global Administrators in Microsoft 365), move the rest to scoped roles, use just-in-time elevation where offered (SCuBA MS.AAD.7.4v1 forbids permanent active assignments for highly privileged roles), deprovision through SCIM, and review admin roles quarterly from the app's own role data. Atlassian organisation admins and ServiceNow admin and security_admin holders need the same treatment. See the Atlassian Cloud Security Guide, the ServiceNow Security Guide and the Access Reviews Guide.
5. Shadow SaaS and unmanaged tenants
The risk: apps adopted through free tiers, trials, expense claims and "Sign in with Microsoft or Google", plus second tenants of approved apps created by a team or a subsidiary. Nobody owns them, nobody reviews their grants, and their tokens and data persist after the project ends.
Why it matters: the Vercel Context.ai OAuth breach began with a forgotten AI app's stolen token. AI assistants are the fastest-growing source of shadow SaaS, because they ask for mailbox, drive and calendar scopes on first use.
The fix: build discovery from four sources, because each misses something: identity provider sign-ins, OAuth grants and service principals, network or browser telemetry, and card and expense data. Every discovered app gets an owner, a data classification and a decision (approve, replace or block) within a set period, and unowned grants are revoked. See the Shadow AI Discovery Guide.
6. Misconfiguration, drift and risk creep
The risk: SaaS risk creep is the slow loosening of an app after approval: an admin relaxes a setting to fix a ticket, the vendor ships a feature that is on by default, an exception has no expiry, and a new integration is added without review. The NCSC warns that "SaaS services can evolve very rapidly", which applies after deployment as much as before.
Why it matters: misconfiguration needs no exploit, and an annual review sees a snapshot, not the eleven months in between.
The fix: scan tier 1 apps daily against a baseline (SCuBA for Microsoft 365 and Google Workspace, the CSA SaaS Security Capability Framework (SSCF) and vendor hardening guides for the rest), store each result so the next run is a diff, keep an exception register with owners and expiry dates, and alert when a high-severity control flips from pass to fail. Read vendor release notes monthly for features enabled by default, especially AI assistants and sharing options.
7. Over-sharing and uncontrolled external access
The risk: "anyone with the link" sharing, guest accounts that never expire, public sites connected to CRM records and wide default permissions on new links (T1530 Data from Cloud Storage).
Why it matters: exposure accumulates silently, one link at a time, and is rarely visible in sign-in logs because no one signs in.
The fix: SCuBA's SharePoint baseline gives testable values: external sharing limited to "Existing guests" or "Only people in your organization" (MS.SHAREPOINT.1.1v1), external sharing restricted to approved domains (1.3v1), default link scope "Specific people" (2.1v1), default permissions view only (2.2v1) and Anyone links expiring in 30 days or less (3.1v1). Apply equivalents in other suites, expire inactive guests and review guest user profiles on every public portal. See the Microsoft 365 Security Guide and the Google Workspace Security Guide.
8. Session and token theft after sign-in
The risk: adversary-in-the-middle phishing kits, infostealers and support files capture session cookies and bearer tokens, which work without the password or MFA until they expire (T1539 Steal Web Session Cookie, T1550.004 Web Session Cookie). MFA prompt bombing (T1621) is the cruder variant.
Why it matters: SSO ends at the identity provider; a session the SaaS app already issued keeps working after the IdP session is revoked. Session tokens in support files were central to the Okta support system breach.
The fix: shorter session lifetimes for admin and tier 1 apps, sign-in restricted to managed devices or known networks where the app supports it, token protection or binding where available, sanitised support files, and a tested "revoke all sessions" step in the account compromise playbook. See the Token and Session Security Guide.
9. Logging gaps and licence-tier blind spots
The risk: the events that prove what an attacker did, such as queries run by an integration, files downloaded or mail items read, often sit behind premium licences, have short retention or are never collected.
Why it matters: GTIG's Drift advice relied on Salesforce Event Monitoring and UniqueQuery events, and noted that the attacker deleted query jobs but the logs were unaffected. Customers without those logs could not say what was taken. The NCSC's baseline is simple: "audit logs should be monitored and any suspicious activity investigated".
The fix: for each tier 1 app, record what is logged at your licence tier, the retention and the export API, decide what you need before an incident, stream logs to the SIEM (SCuBA MS.AAD.4.1v1 requires security logs to reach the security operations centre) and alert on audit settings changing. Watch for discovery through admin consoles (T1538 Cloud Service Dashboard). See the SIEM Guide.
10. Cross-SaaS blast radius: secrets in SaaS data and chained tenants
The risk: support cases, tickets, wiki pages and chat messages hold pasted API keys, passwords and tokens, and one SaaS identity or token often reaches several platforms. Bulk collection from one app (T1213.004 Customer Relationship Management Software, T1213.005 Messaging Applications) becomes access to the next, followed by exfiltration (T1567 Exfiltration Over Web Service).
Why it matters: after the Drift data theft, GTIG says the actor searched the stolen data for AWS keys (the AKIA prefix), passwords and Snowflake access tokens. The Commvault Metallic breach showed that a SaaS backup service holds app secrets for the tenants it protects. This is cross-SaaS risk: the weakest connected app sets the exposure of the strongest.
The fix: scan SaaS records for secrets and rotate what you find, restrict bulk export and data loader tools to named roles, set alerts on query volume per integration user (GTIG recommends Transaction Security Policies for "large data downloads"), and map which tokens and identities connect which apps so one compromise triggers revocation everywhere it reaches. See the Third-Party Access Guide and the Leaked Credential Response Playbook.
Mapping to OWASP
OWASP has no SaaS Top 10. The closest fit is the OWASP Non-Human Identities Top 10 (2025), because half of these risks are integration users, OAuth apps and tokens. ATT&CK's SaaS matrix, the SCuBA baselines and NIST SP 800-210 section 5 (Access Control Guidance for SaaS) give the technique and control view.
| Risk | ATT&CK v20 (SaaS matrix) | OWASP NHI Top 10 2025 | Example control |
|---|---|---|---|
| 1. Credentials and weak sign-in | T1078.004, T1110.003, T1110.004 | NHI4 Insecure Authentication (integration users) | MS.AAD.1.1v1, MS.AAD.3.1v1 |
| 2. Over-scoped integrations | T1528, T1199 | NHI3 Vulnerable Third-Party NHI; NHI5 Overprivileged NHI; NHI7 Long-Lived Secrets | Minimum scopes, IP restriction on connected apps |
| 3. Consent phishing | T1671, T1566 | NHI3 Vulnerable Third-Party NHI | MS.AAD.5.1v1 to 5.3v1 |
| 4. Identity sprawl | T1098.003 | NHI1 Improper Offboarding; NHI5 Overprivileged NHI | MS.AAD.7.1v1, MS.AAD.7.4v1; SP 800-210 5.3 |
| 5. Shadow SaaS | T1078.004, T1528 | NHI1 Improper Offboarding | Discovery and app register |
| 6. Drift and risk creep | None direct (enables the rest) | NHI6 Insecure Cloud Deployment Configurations (weak fit) | Baseline diff scans; SSCF |
| 7. Over-sharing | T1530 | None | MS.SHAREPOINT.1.1v1 to 3.1v1 |
| 8. Session theft | T1539, T1550.004, T1621 | None | Session lifetime and device binding |
| 9. Logging gaps | T1538 (discovery goes unseen) | None | MS.AAD.4.1v1 |
| 10. Cross-SaaS blast radius | T1213.004, T1213.005, T1567 | NHI2 Secret Leakage; NHI9 NHI Reuse | Secret scanning of records; export limits |
Where to start
If you can do only three things this quarter: close sign-in back doors and enforce phishing-resistant MFA on tier 1 apps (risk 1), switch user consent to admin approval and review existing grants (risks 2 and 3), and inventory every integration with its scopes, owner and last use (risk 2). Then turn on log streaming for tier 1 apps (risk 9), because every other control is unprovable without it.
Scoring and tiering SaaS risk
A SaaS risk score turns this list into a register you can sort. Score each app, and each integration, on the factors below, then tier the estate: tier 1 gets daily baseline scans, log streaming and quarterly admin and integration reviews; tier 2 gets monthly scans and six-monthly reviews; tier 3 needs SSO, an owner and an annual check. The weights are a starting point, not a standard.
| Factor | Low (1) | High (3) | Suggested weight |
|---|---|---|---|
| Data sensitivity | Public or internal only | Customer, financial, health or source code data | x3 |
| Sign-in strength | SSO only, phishing-resistant MFA, no local login | Local passwords or no MFA | x2 |
| Integration exposure | No third-party tokens, or read-only scoped grants | Full or offline scopes, no IP restriction | x2 |
| Admin footprint | Two to eight admins, JIT elevation | Many standing admins or shared admin accounts | x2 |
| External sharing | Internal only or allow-listed domains | Anyone links, unexpired guests, public portals | x1 |
| Visibility | Audit logs streamed and alerted | No log feed or short retention | x1 |
| Supplier assurance | Assessed against the SSCF, current attestation | Never assessed | x1 |
SaaS risk correlation is where scoring pays off. Single findings rarely matter alone; combinations do: an admin with no MFA in an app that also has a full-scope integration and no log feed is an incident waiting to happen. Correlate across apps too: an identity or token that reaches several tier 1 apps raises the score of all of them, and a supplier that integrates with several of your apps is one third-party SaaS risk, not several. Track five numbers monthly: tier 1 apps with any password-only sign-in path (target zero), integrations with full or offline scopes, integration tokens unused for 90 days, high-severity baseline controls in fail state for more than 30 days, and tier 1 apps without a live log feed (target zero).
Standards and references
- CISA: Secure Cloud Business Applications (SCuBA) Project
- CISA: SCuBA Microsoft Entra ID (Azure AD) Baseline
- CISA: SCuBA SharePoint Online and OneDrive Baseline
- NIST: SP 800-210, General Access Control Guidance for Cloud Systems
- NCSC: Understanding Software as a Service (SaaS) security
- Cloud Security Alliance: SaaS Security Capability Framework (SSCF)
- MITRE ATT&CK: SaaS Matrix
- Google Threat Intelligence Group: Widespread Data Theft Targets Salesforce Instances via Salesloft Drift
Related NHI Mgmt Group resources: SaaS Security Guide · SaaS and OAuth App Governance Guide · Entra ID Applications and Consent Guide · SaaS Security Buyer's Guide · Third-Party Access Guide