Most security teams believe their biggest exposure lives outside of their SaaS applications. In reality, the real threat often sits one integration away. API security has quietly become the foundation of SaaS supply chain security, yet it remains one of the most overlooked attack surfaces in modern enterprise environments.
According to Obsidian's network data, SaaS-to-SaaS data moves 10x faster than human-to-SaaS interactions. This velocity creates both business value and security risk. When API credentials are compromised, attackers ride those trusted connections straight into customer environments, bypassing the security controls that protect human access.
Key Takeaways
- APIs create a hidden layer between SaaS applications that operates outside SSO and MFA controls, enabling attackers to bypass traditional security measures through compromised credentials
- Static API inventories fail immediately because they lack behavioral context and cannot detect when legitimate API credentials are being abused by attackers
- Bearer tokens and API keys function like master keys that grant access without requiring authentication, making token theft and replay attacks particularly dangerous
- Behavioral monitoring is essential for detecting anomalies in API activity patterns, including unusual data exports, IP address deviations, and suspicious access patterns
- SaaS supply chain breaches increasingly originate from compromised API integrations, as demonstrated by incidents like CircleCI and Snowflake where stolen API credentials enabled widespread lateral movement
What is API Security?
API security is the practice of protecting the programmatic connections between software systems from unauthorized access, data exposure, and credential abuse. In SaaS environments, APIs form the hidden layer where applications communicate outside traditional controls like SSO and MFA; making them a critical attack surface that requires continuous visibility, behavioral monitoring, and governance to secure.
Unlike traditional security controls that focus on protecting human users logging into applications, API security must address non-human identities including service accounts, OAuth tokens, API keys, and webhooks. These machine identities operate continuously in the background, often with elevated privileges that exceed what any individual user possesses.
APIs serve as the backbone of SaaS-to-SaaS communication. When you connect your marketing automation platform to your CRM, that integration relies on APIs. When your analytics dashboard pulls data from multiple sources, APIs make it possible. When your helpdesk system creates tickets based on customer emails, APIs orchestrate that workflow.
Most SaaS APIs implement OAuth tokens as bearer tokens, functioning like physical keys. Whoever possesses the token can use it, regardless of how they obtained it. There is no additional authentication challenge, no MFA prompt, and no behavioral analysis to verify the token holder's legitimacy. This design prioritizes convenience and performance but creates significant security exposure when tokens are stolen or leaked.
Why API Security Matters for SaaS Environments
APIs quietly extend trust beyond the security perimeter organizations carefully construct around their core applications. When a security team implements SSO, enforces MFA, and monitors user behavior within Salesforce, they often overlook the dozen integrations that have direct API access to that same Salesforce environment.
The hidden layer problem is fundamental to understanding API security risk. While security teams focus on protecting the front door with SSO and MFA, APIs create side entrances that bypass these controls entirely. A compromised OAuth refresh token or stolen API key grants access without ever triggering an authentication flow that security tools can monitor.
The Salesloft-Drift incident revealed another dimension of API security risk: cascading exposure through integration chains. When one SaaS vendor experiences a breach, the OAuth integrations connecting that vendor to customer environments become attack pathways. In this case, a single compromised integration extended into tools like Gainsight and multiple Salesforce instances, multiplying the blast radius to more than 700 companies.
What makes API security particularly challenging is that these connections operate with inherited permissions. When you authorize a third-party application to access your Salesforce data, that application receives permissions based on the authorizing user's access level. If a Salesforce admin authorizes the integration, the third-party app inherits admin-level access. These overprivileged permissions often persist long after the business need expires, creating stale integrations with admin permissions that represent toxic combinations of broad access and inactive oversight.
Traditional security controls fail to address this risk because they focus on the wrong layer. SSO protects the authentication moment when a human logs in. MFA adds a second factor to that authentication. But OAuth tokens and API keys function independently of your SSO and MFA infrastructure. Once issued, they grant access until explicitly revoked, regardless of changes to the user's authentication status or the security posture of the connected application.
Understanding AI agent security becomes increasingly important as organizations deploy autonomous agents that rely heavily on API access to perform their functions across multiple SaaS applications.
Common API Security Vulnerabilities in SaaS
Broken Authentication & Authorization
The most fundamental API security vulnerability stems from treating API keys as static passwords rather than dynamic credentials requiring continuous validation. Many SaaS integrations rely on long-lived API keys that never expire, creating persistent access that attackers can exploit indefinitely once obtained.
Overprivileged API access represents another critical authentication failure. When security teams authorize an integration, they often grant broad permissions to ensure functionality without considering the principle of least privilege. These permissions are rarely revisited, even as business requirements change or the integration falls into disuse.
The problem compounds because API authorization typically lacks the contextual awareness that protects human access. When a user suddenly accesses sensitive data they have never touched before, behavioral analytics can flag the anomaly. When an API integration does the same thing, most security tools interpret it as normal machine behavior.
OAuth scopes should limit what an integration can access, but many SaaS applications request overly broad scopes, and security teams approve them without scrutiny. An integration that needs read-only access to contact records might request and receive full read-write-delete permissions across all Salesforce objects. This scope creep creates unnecessary risk.
Exposed API Keys
API keys embedded in code repositories, configuration files, and build pipelines create persistent exposure that attackers actively scan for. GitHub alone removes millions of exposed secrets annually, yet new credentials appear daily as developers prioritize speed over security.
The risk extends beyond public repositories. API keys in logs create another exposure vector. When applications log API requests for debugging purposes, they often capture the full request including authentication headers. These logs may be stored in systems with weaker access controls than the production environment, creating a secondary attack surface.
Build pipelines and CI/CD systems represent particularly attractive targets because they often store API credentials for multiple environments and services. The CircleCI breach exploited exactly this concentration of secrets, providing attackers with a treasure trove of API access across numerous customer environments.
A single leaked API key can unlock multiple integrations because developers often reuse credentials across environments or services. What appears to be a single exposure may actually provide access to development, staging, and production environments simultaneously.
Insufficient Rate Limiting & Monitoring
APIs lack behavioral context in most security implementations. While security teams monitor user login patterns, session durations, and data access behaviors, API activity often flows through blind spots in the security architecture.
Traditional monitoring tools focus on human-to-SaaS interactions because that is where historical threats are concentrated. But as attackers shift to exploiting API credentials, these tools miss the lateral movement happening through machine-to-machine communication channels.
Rate limiting, when implemented, typically focuses on preventing denial-of-service attacks rather than detecting data exfiltration. An API integration making thousands of requests per hour might trigger rate limits designed to prevent system overload, but an attacker making hundreds of requests to slowly exfiltrate sensitive data often flies under the radar.
The velocity of API communication makes manual monitoring impossible. SaaS-to-SaaS data moves 10x faster than human-to-SaaS, creating a volume challenge that requires automated behavioral analysis to identify anomalies within legitimate traffic patterns.
Shadow APIs & Undocumented Endpoints
The ease of creating SaaS integrations has democratized API access beyond IT and security teams. Employees create integrations with one OAuth click, connecting productivity tools, automation platforms, and analytics services without security review or documentation.
These shadow APIs accumulate over time, creating an expanding attack surface that security teams cannot see, much less protect. When a vendor breach notification arrives, security teams scramble to determine whether their organization uses the affected service, often discovering integrations they never knew existed.
The problem intensifies with low-code and no-code platforms that enable business users to build workflows connecting multiple SaaS applications through API integrations. Each workflow creates new API connections, new data flows, and new security exposure that traditional discovery tools miss.
Undocumented endpoints within sanctioned applications create additional risk. SaaS vendors may expose API functionality for internal use or specific customer implementations without documenting these endpoints publicly. Attackers who discover these endpoints can exploit functionality that security teams do not know exists and therefore cannot monitor or protect.
Organizations exploring AI agent visibility face similar challenges as autonomous agents create dynamic API connections to accomplish their tasks.
Why Traditional Security Tools Fail to Secure APIs
Legacy security tools were built for a different threat model. Network perimeter tools assume that threats come from outside and that protecting the boundary between internal and external networks provides adequate security. But SaaS applications live outside the traditional network perimeter, and API connections between SaaS apps create trust relationships that perimeter tools cannot see or control.
CASBs (Cloud Access Security Brokers) provide visibility into user traffic between corporate networks and cloud applications. They can monitor what data employees upload to Salesforce or download from Box. But CASBs typically miss backend API-to-API communication because that traffic does not flow through the CASB proxy. When Salesforce syncs data to your marketing automation platform via API, that connection happens directly between the two cloud services, invisible to CASB monitoring.
Static inventories represent another failed approach to API security. Many organizations maintain spreadsheets or databases listing their SaaS integrations, API keys, and service accounts. These inventories become outdated immediately because they capture only a snapshot in time. New integrations appear daily as employees connect tools to accomplish their work. Existing integrations change permissions, rotate keys, or fall into disuse without updating the inventory.
More fundamentally, static inventories lack behavioral context. Knowing that an integration exists tells you nothing about whether it is currently being abused. A legitimate API key stolen by an attacker looks identical to that same key used by the authorized integration. Static inventory tools cannot differentiate between normal and malicious use of valid credentials.
SIEM (Security Information and Event Management) platforms can ingest API logs, but they struggle with the volume and velocity of API traffic. SaaS-to-SaaS communication generates massive log volumes that overwhelm SIEM systems designed for human-scale activity. Even when properly configured, SIEMs lack the SaaS-specific context needed to distinguish normal API behavior from compromise.
The fundamental problem is that traditional tools focus on inventory rather than behavior. They answer the question "what integrations do we have?" but cannot answer "which integrations are behaving abnormally?" or "which API credentials have been compromised?" Detecting compromised API credentials requires understanding normal behavior patterns for each integration and identifying deviations that indicate abuse.
Network security tools also fail because API security requires identity context. Understanding whether an API request is legitimate requires correlating the request back to the identity that authorized the integration, the business purpose that justified the access, and the historical behavior pattern that establishes a baseline. Traditional network tools see only IP addresses, request volumes, and payload sizes without the identity and business context needed to assess risk.
Organizations implementing continuous SaaS security monitoring recognize that point-in-time assessments cannot keep pace with the dynamic nature of API integrations.
API Security Best Practices for SaaS Integrations
Implement Least Privilege for API Access
Audit API permissions regularly to identify integrations with excessive access relative to their business function. An integration that synchronizes contact information between your CRM and marketing platform should not have delete permissions on financial records or administrative access to user management functions.
The challenge is that OAuth scopes often come in coarse-grained bundles. A SaaS application might request "full access" to Salesforce when it only needs read access to contact records. Security teams must push back on overly broad scope requests and work with vendors to implement more granular permissions.
Identify toxic combinations where broad access meets inactive usage. An integration that has not been used in six months but retains admin-level permissions represents exactly the kind of stale, overprivileged access that attackers seek. These dormant integrations provide low-resistance paths for lateral movement because they trigger no alerts when suddenly activated.
Implementing least privilege for APIs requires understanding not just what permissions an integration has, but what permissions it actually uses. Behavioral analysis can reveal that an integration authorized for read-write-delete operations only ever performs read operations, indicating that permissions can be safely reduced.
Rotate API Keys and Use Short-Lived Tokens
Treat API keys like credentials, not static passwords. Just as security teams enforce password rotation policies for human users, API keys require regular rotation to limit exposure windows. A compromised API key that expires in 90 days presents far less risk than one that remains valid indefinitely.
Prefer OAuth tokens with expiration over long-lived API keys whenever possible. OAuth refresh tokens enable applications to obtain new access tokens without requiring manual intervention, providing a balance between security (short-lived access tokens) and convenience (automated renewal).
The distinction between access tokens and refresh tokens matters for security. Access tokens typically expire within hours, limiting the window of opportunity for attackers who steal them. Refresh tokens last longer but should still have defined expiration periods. Refresh token security requires particular attention because these tokens can generate new access tokens, making them especially valuable to attackers.
Implement processes to revoke API credentials when employees leave, projects end, or integrations are decommissioned. Many organizations discover during security audits that they have dozens of active API keys for integrations that no longer serve any business purpose.
Monitor API Behavior, Not Just Inventory
Static lists miss compromised credentials acting normally. An attacker using stolen API credentials generates requests that appear legitimate because they use valid authentication. Detecting this abuse requires understanding what normal looks like for each integration and identifying deviations.
Behavioral analytics detect anomalies including unusual data export volumes, access patterns that differ from historical baselines, requests originating from unexpected IP addresses or geographic regions, and API calls to endpoints the integration has never previously accessed.
ASN (Autonomous System Number) deviation provides a particularly effective signal for detecting compromised API credentials. Legitimate integrations typically originate from consistent network infrastructure. When API requests suddenly come from a different ASN, especially one associated with residential proxies or VPN services, it indicates potential credential theft.
User-Agent attribution offers another behavioral signal. APIs typically identify themselves with consistent User-Agent strings. Changes to this string can indicate that credentials are being used by different software than originally authorized.
The velocity and volume of API requests also provide behavioral signals. An integration that typically makes 100 requests per hour suddenly making 1,000 requests deserves investigation. Similarly, an integration that usually transfers megabytes of data suddenly exfiltrating gigabytes indicates potential compromise.
Organizations focused on AI detection and response apply similar behavioral monitoring principles to identify anomalous activity patterns.
Discover and Govern Shadow APIs
Inventory all API integrations including unsanctioned ones. Discovery must be continuous rather than point-in-time because new integrations appear constantly as employees connect tools to accomplish their work.
Effective discovery requires visibility into OAuth authorizations across all core SaaS applications. When an employee authorizes a third-party app to access Salesforce, that authorization creates an integration that security teams need to know about, evaluate, and potentially revoke if it violates policy.
Map data flows between connected SaaS applications to understand how information moves through your SaaS supply chain. An integration that seems low-risk in isolation may create significant exposure when you understand that it has access to data from multiple upstream sources and forwards that data to downstream applications.
Shadow API discovery must account for integrations created through multiple mechanisms including OAuth authorizations, API key generation, service account creation, and webhook configurations. Each mechanism creates API access through different paths that require different discovery approaches.
Governance policies should define approval workflows for new integrations, periodic recertification requirements for existing integrations, and automatic deprovisioning for integrations that fail recertification or exceed defined risk thresholds.
Integrate API Security with Identity Context
Correlate API activity back to identity to understand who authorized each integration, what business purpose justified the access, and whether the authorizing user still works for the organization or has changed roles.
This correlation enables security teams to answer critical questions: When an integration behaves suspiciously, who should we contact to verify whether the activity is legitimate? When an employee leaves, which integrations did they authorize that now require review or revocation?
Differentiate normal integration traffic from attacker abuse by building behavioral baselines that incorporate identity context. An integration authorized by a marketing employee that suddenly accesses financial data should trigger alerts even if the API credentials are valid and the request volume seems normal.
Knowledge Graph correlation connects API integrations to the users who authorized them, the data they access, the permissions they hold, and the other integrations they interact with. This interconnected view enables security teams to assess risk holistically rather than evaluating each integration in isolation.
Understanding SaaS supply chain security requires this holistic view of how API integrations create trust relationships that extend beyond your direct control.
How Obsidian Security Approaches API Security
Obsidian Security provides unified visibility into all API integrations across core SaaS applications, addressing the blind spots where attackers operate. Rather than relying on static inventories that become outdated immediately, Obsidian continuously discovers OAuth authorizations, service accounts, API keys, and webhooks across your SaaS environment.
Behavioral activity modeling forms the foundation of Obsidian's approach. By establishing baselines for normal API behavior and detecting deviations that indicate compromise, Obsidian can identify when legitimate credentials are being abused. This includes detecting unusual data exports, IP address deviations, unexpected API endpoints being accessed, and velocity changes that suggest automated data exfiltration.
Risk scoring identifies overprivileged, stale integrations that represent toxic combinations of broad access and inactive oversight. Obsidian quantifies risk by analyzing factors including permission scope, last usage timestamp, data sensitivity, and the security posture of connected applications. This enables security teams to prioritize remediation efforts on the integrations that present the greatest exposure.
The Knowledge Graph correlates API activity with identity context, connecting each integration back to the user who authorized it, the business justification for the access, and the data flows enabled by the integration. This correlation enables security teams to assess risk holistically and respond effectively when anomalies are detected.
Obsidian's approach recognizes that behavior trumps inventory. While maintaining an accurate inventory of integrations provides value, detecting compromised credentials requires understanding how each integration normally behaves and identifying deviations that indicate abuse. This behavioral focus enables detection of threats that static tools miss entirely.
The platform addresses the operational burden security teams face when trying to manually track integrations across multiple SaaS applications. Rather than maintaining spreadsheets that become outdated immediately, Obsidian provides automated discovery and continuous monitoring that scales with the pace of SaaS adoption.
Organizations concerned about AI agent security risks benefit from Obsidian's ability to monitor the API integrations that autonomous agents rely upon to function.
Conclusion
API security is foundational to SaaS supply chain security. The invisible connections between SaaS applications create a hidden layer where attackers can move laterally, exfiltrate data, and establish persistence without triggering traditional security controls designed to protect human access.
Static approaches fail because they lack the behavioral context needed to detect when legitimate API credentials are being abused. An accurate inventory of integrations tells you what exists but cannot reveal which credentials have been compromised. Behavioral detection is required to identify anomalies in API activity patterns that indicate compromise.
The real exposure sits one integration away. When security teams focus exclusively on protecting direct access to their core applications, they overlook the dozens or hundreds of integrations that have API access to those same environments. Each integration represents a potential attack path that bypasses SSO, MFA, and other authentication controls.
Security teams must shift from inventory-focused approaches to behavioral monitoring that can detect compromised credentials acting within their authorized permissions. This requires understanding normal behavior patterns for each integration, correlating API activity back to identity context, and identifying deviations that indicate abuse.
The incidents at CircleCI, Snowflake, and the Salesloft-Drift integration cascade demonstrate that API security risks are not theoretical. Attackers actively target API credentials because they provide direct access that bypasses traditional security controls. Organizations that fail to address API security will continue experiencing breaches that originate from compromised integrations.
Next steps for security teams:
- Conduct a comprehensive discovery of all API integrations across core SaaS applications
- Identify overprivileged, stale integrations that represent toxic combinations
- Implement behavioral monitoring to detect anomalies in API activity patterns
- Establish governance policies for integration approval and periodic recertification
- Correlate API activity back to identity context to enable effective incident response
The SaaS supply chain will continue expanding as organizations adopt more applications and create more integrations. Security strategies must evolve to address the hidden layer where APIs quietly extend trust beyond traditional controls. Behavioral detection provides the visibility and context needed to secure this expanding attack surface.
