Why Hackers Love Your SaaS Apps: The Security Blind Spots Most Companies Miss

Your team runs on SaaS. Sales lives in Salesforce. Finance works out of Xero. Everyone communicates through Slack or Microsoft Teams. Documents flow through Google Workspace or SharePoint. Onboarding, HR, payroll, project management: all cloud, all SaaS, all connected.

Attackers know this. And they have adjusted accordingly.

The assumption that SaaS is secure by default because someone else is running the infrastructure is one of the most expensive mistakes a company can make. The platform provider secures the infrastructure. You are responsible for everything else: who has access, what permissions they hold, how data is shared, which third-party apps are connected, and whether any of it is reviewed after the initial setup.

Most companies set up their SaaS tools once and never look back. That is exactly the window attackers are walking through.

Why SaaS Is a High-Value Target

SaaS applications are attractive targets for a simple reason: they concentrate enormous amounts of sensitive data and are accessible from anywhere in the world with valid credentials.

A compromised Microsoft 365 account does not just give an attacker access to someone's email. It gives access to SharePoint files, Teams conversations, calendar events, OneDrive documents, and potentially every integration that account is connected to. The blast radius of a single compromised identity in a well-integrated SaaS environment is significant.

The attack surface has expanded faster than most security programs have adapted. Organizations now manage dozens of SaaS applications on average, each with its own permission model, sharing settings, and third-party integrations. According to research published in 2025, the average mid-sized company connects over 100 SaaS applications to its core productivity platforms. Each connection is a potential entry point.

What makes SaaS particularly difficult to defend is that the threats do not come primarily from technical vulnerabilities in the platform code. They come from configuration decisions made by administrators and end users who were optimizing for speed and convenience, not security. Attackers do not need to find a zero-day. They need to find the setting that was left open.

The Most Common SaaS Vulnerabilities

The same categories of weakness appear repeatedly across SaaS environments of different sizes and industries. They are not exotic. They are the predictable result of rapid adoption without structured security oversight.

Overprivileged accounts. When users are granted administrative or broad permissions to get something done quickly, those permissions rarely get reviewed afterward. A project manager given temporary admin rights to configure a new integration two years ago may still hold those rights today. Privileged access that is not actively managed is access that is waiting to be abused.

Inactive users with active accounts. Former employees, contractors who finished a project, consultants brought in for a specific engagement: all of them may still have live accounts with valid credentials. Research from SaaS Alerts covering over four million monitored accounts found that more than half were guest or inactive user accounts. Each one is a dormant entry point.

OAuth app sprawl. Every time a user connects a third-party tool to a core platform by clicking "Allow access," they create a persistent authorization that often outlives the use case. That connected app retains API-level access to the platform even if the user stops using it, even after a password reset, and sometimes even after MFA is enforced. A finding from Valence Security showed that 65% of third-party integrations in Microsoft 365 environments were inactive yet still held valid tokens.

MFA disabled for convenience. Multi-factor authentication is turned off for specific accounts, service accounts, or legacy integrations because it creates friction. Snowflake's 2024 breach involved customer environments where MFA was not enforced, allowing credential-based attacks to succeed at scale. The same pattern repeats in breach after breach.

Misconfigured sharing settings. Files shared externally via a link that never expires. Folders accessible to anyone with the link. SharePoint sites with public visibility that no one noticed. Research covering Microsoft 365 environments found that over 37 million files were shared externally in a single year, many through open links that remained active long after their intended use.

Microsoft 365 and Google Workspace: The Specific Risk

These two platforms deserve individual attention because they sit at the center of most organizations' SaaS ecosystems and because attackers have refined their approach to compromising them specifically.

In Microsoft 365, the most exploited attack paths include password spray attacks against accounts without MFA, legacy authentication protocols that bypass modern conditional access policies, and OAuth token abuse that maintains access even after a compromised account's password is changed.

The Midnight Blizzard breach, which affected Microsoft's own environment, started with a password spray attack against a test tenant that had no MFA configured. The attackers then moved laterally using a legacy OAuth token and created additional malicious OAuth applications to extend their access while avoiding detection.

In Google Workspace, the risks are structurally similar but manifest differently. Overly permissive Google Drive sharing settings expose data to anyone with a link. Third-party apps connected through Google's OAuth flow often retain read access to Gmail, Drive, and Contacts long after they are no longer actively used. Admin console misconfigurations can allow external users to join organization-wide resources or access shared drives that were intended to be internal.

The common thread is that neither platform is insecure by design. Both offer extensive controls for access management, external sharing, conditional access, and third-party app governance. The problem is that those controls require active configuration, ongoing monitoring, and regular review. Out of the box, both platforms prioritize usability over restriction.

What Attackers Actually Do Once Inside

Understanding what happens after an initial compromise helps explain why SaaS breaches tend to be more damaging than they initially appear.

The first objective for most attackers after gaining access to a SaaS account is reconnaissance. They explore what the account can access, what integrations exist, what data is available, and whether there are higher-privileged accounts to target. In a well-connected SaaS environment, this reconnaissance can be conducted entirely through legitimate platform features, making it difficult to distinguish from normal user behavior.

Lateral movement in SaaS environments does not require exploiting technical vulnerabilities. An attacker with access to one account can send messages from that account to other users, request access to shared resources, or approve OAuth applications that extend their reach. Because these actions look like legitimate user behavior, they often go undetected for weeks.

Data exfiltration follows naturally from this access. Sensitive files, email threads, customer data, financial records, and intellectual property can be downloaded, forwarded externally, or shared via open links without triggering alerts in organizations that do not have SaaS-specific monitoring in place.

Business email compromise is a related but distinct threat. An attacker with access to an executive's Microsoft 365 or Google Workspace account can read ongoing email threads, understand payment processes, and insert fraudulent instructions at precisely the right moment. These attacks do not require the attacker to send messages from an unfamiliar address. They use the real account, which means standard email security tools do not flag them.

How a SaaS Security Review Differs from a Standard Pentest

A traditional penetration test focuses on network infrastructure, web applications, and external-facing systems. It is designed to find vulnerabilities in technical controls: open ports, unpatched software, injection vulnerabilities, authentication weaknesses in web applications.

A SaaS security review has a different scope and methodology. It examines configuration state, not just technical vulnerabilities. The questions being asked are: who has access to what, what third-party apps are connected and what permissions do they hold, how is external sharing configured, where are the policy gaps, and what would an attacker find if they compromised a standard user account.

This requires reviewing administrative consoles, analyzing permission structures, mapping connected applications, and understanding data flows. It is less about attacking systems and more about understanding the state of access and configuration across a complex environment.

The output is a prioritized findings report covering misconfigured settings, overprivileged accounts, inactive access, and external exposure, along with remediation guidance that can be acted on without a major infrastructure change. Many SaaS security findings are fixed through configuration changes rather than code changes, which means remediation timelines are often much shorter than those from a traditional pentest.

Three Things You Can Check Before the End of This Week

A full SaaS security review takes time to scope and conduct properly. But there are three checks any company can run against its own environment in the next few days that will surface meaningful risk.

First, pull a list of all OAuth applications connected to your Microsoft 365 or Google Workspace environment and identify which ones have not been accessed in the past 90 days. Any application with persistent access and no recent activity is a candidate for revocation.

Second, run a report on external file sharing in your primary document platform. Look for files or folders shared via open links, shared with personal email addresses, or shared with "anyone with the link" permissions. The volume of results is often surprising to administrators who have never run this report before.

Third, identify all accounts in your environment that do not have MFA enforced. This includes service accounts, shared mailboxes, and any accounts created for integrations or legacy purposes. Each one without MFA is a single-credential entry point.

These three checks will not give you a complete picture of your SaaS security posture. But they will almost certainly surface issues that warrant immediate attention, and they cost nothing except the time to run the reports.

Getting a Complete Picture

The checks above reveal what is easy to find. A structured SaaS security review reveals what is not.

ESKA's penetration testing and cloud security assessment services cover SaaS environments alongside network and application infrastructure. Our team reviews configuration state, access structures, third-party integrations, and external sharing settings to give organizations a complete picture of where their SaaS exposure lies and what to prioritize.

If your organization has grown its SaaS footprint without a corresponding review of how it is configured and who has access to what, contact us to discuss what a SaaS-focused assessment looks like for your environment.