Most security teams believe their SaaS applications are protected once SSO and MFA are deployed. In reality, webhooks create automated data pipelines that operate completely outside traditional authentication controls. These real-time HTTP callbacks quietly move sensitive data between applications, and when compromised, they become invisible highways for attackers to exfiltrate information, inject malicious payloads, or establish persistent backdoors.
Webhook security represents one of the most overlooked attack surfaces in modern SaaS supply chain security. Unlike OAuth integrations that users explicitly authorize, webhooks often run silently in the background, configured once by administrators and forgotten. Yet they carry the same level of access, processing customer data, financial records, and authentication events without ongoing scrutiny.
Webhooks are automated HTTP callbacks that enable real-time data synchronization between applications. When a specific event occurs in one system (the source), that application sends an HTTP POST request containing event data to a predefined URL endpoint (the destination). This creates an event-driven architecture where applications can react immediately to changes without constant polling.
Unlike API calls where Application A requests data from Application B, webhooks reverse this relationship. Application B pushes data to Application A the moment something happens. This fundamental difference makes webhooks incredibly efficient for real-time integrations but also creates unique security challenges.
Consider a common business scenario: when a new customer signs up in your CRM (Salesforce), you want that contact automatically created in your marketing automation platform (Marketo), your customer success tool (Gainsight), and your billing system (Stripe). Webhooks make this possible.
The technical flow works like this:
This entire sequence happens in milliseconds, creating seamless data synchronization across your SaaS supply chain.
While both webhooks and OAuth tokens enable SaaS integrations, they operate through different mechanisms:
Aspect
Webhooks
OAuth Integrations
Direction
Push (source sends to destination)
Pull (destination requests from source)
Authentication
API keys, shared secrets, signatures
OAuth tokens (access tokens and refresh tokens)
User Context
No user identity attached
Tied to authorizing user account
Visibility
Often configured at admin level
Users see OAuth consent screens
Persistence
Runs until manually disabled
Tokens can expire or be revoked
Both represent non-human identities that operate independently of SSO and MFA controls. Both create the "one integration away" risk where a compromised third party becomes a direct pathway into your environment.
Security teams face a harsh reality: the SaaS applications you don't directly control often pose greater risk than those you manage internally. Webhooks amplify this exposure because they create persistent, automated connections that operate in the hidden layer between applications.
Most organizations have dozens or hundreds of active webhooks. According to Obsidian's network data, the average enterprise maintains 47 active webhook endpoints across their SaaS ecosystem, with security teams able to document only 23% of them in their integration inventories. This gap represents blind spots where attackers operate undetected.
Webhooks remain invisible to traditional security controls:
This visibility gap creates operational challenges. When a vendor sends a breach notification, security teams scramble to answer basic questions: Which of our applications send webhooks to this vendor? What data do those webhooks transmit? How many customer records are exposed?
Scenario 1: Vendor Breach Lateral Movement
When a SaaS vendor suffers a breach, attackers gain access to the vendor's infrastructure, including databases containing customer webhook configurations. These configurations include:
Armed with this information, attackers can replay webhook requests to customer environments, injecting malicious payloads that appear to originate from the trusted vendor. The receiving application processes these requests as legitimate because the authentication credentials are valid.
Scenario 2: Webhook Endpoint Takeover
Organizations frequently change their infrastructure; migrating to new domains, decommissioning old servers, or restructuring their architecture. Webhook endpoints pointing to deprecated URLs create takeover opportunities. Attackers can register expired domains or claim abandoned cloud resources, then receive all webhook traffic intended for the original endpoint.
Scenario 3: API Key Exposure
Webhooks authenticate using API keys, shared secrets, or HMAC signatures. These credentials often appear in:
Once exposed, these credentials enable attackers to impersonate legitimate webhook sources, sending crafted payloads to trigger unintended actions in receiving applications.
The Salesloft-Drift incident demonstrated how webhook compromise cascades across the SaaS supply chain. When Drift experienced a security incident, the exposure extended through their integration ecosystem. Organizations using Drift's webhooks to synchronize data with Salesforce, Gainsight, and other platforms suddenly faced a multiplier effect; one compromised vendor created exposure across multiple downstream applications.
This represents the core challenge of SaaS supply chain risk: your security posture depends not only on your direct vendors but also on the security practices of every application those vendors integrate with. Webhooks create the technical mechanism that transforms a single vendor breach into a multi-application incident.
Regulatory frameworks increasingly focus on third-party risk management and data flow documentation. GDPR, CCPA, HIPAA, and SOC 2 all require organizations to maintain accurate inventories of systems processing sensitive data.
Webhooks complicate compliance in several ways:
During compliance audits, organizations struggle to demonstrate control over webhook-mediated data flows. The question "what systems have access to customer PII?" becomes exponentially harder to answer when webhooks create dynamic, undocumented connections.
Securing webhooks requires a multi-layered approach that addresses authentication, authorization, data protection, and behavioral monitoring. Unlike user identities protected by SSO and MFA, webhooks represent machine identities that demand different security controls.
API Keys and Shared Secrets
The most common webhook authentication method uses API keys or shared secrets. The webhook source includes a secret token in the HTTP request (typically in headers), and the destination verifies this token before processing the payload.
POST /webhook/endpoint HTTP/1.1
Host: destination-app.com
X-API-Key: sk_live_51H8K2jKl3m4n5o6p7q8r9s0
Content-Type: application/json
{"event": "customer.created", "data": {...}}
Limitations: API keys function as bearer tokens; whoever possesses the key gains full access. If the key leaks through code repositories, logs, or network interception, attackers can impersonate the legitimate webhook source.
HMAC Signature Verification
More sophisticated implementations use HMAC (Hash-based Message Authentication Code) signatures. The webhook source creates a cryptographic hash of the payload using a shared secret, includes this signature in the request headers, and the destination independently computes the hash to verify authenticity.
POST /webhook/endpoint HTTP/1.1
Host: destination-app.com
X-Webhook-Signature: sha256=a3b4c5d6e7f8g9h0i1j2k3l4m5n6o7p8
Content-Type: application/json
{"event": "customer.created", "data": {...}}
The receiving application:
This approach prevents payload tampering and replay attacks (when combined with timestamp validation), but the shared secret still represents a single point of failure.
Mutual TLS (mTLS)
Enterprise implementations may use mutual TLS, where both the webhook source and destination present certificates to verify identity. This provides stronger authentication but requires certificate management infrastructure and is less common in SaaS-to-SaaS integrations.
Authentication answers "who is sending this webhook?" Authorization answers "what should this webhook be allowed to do?"
Many webhook implementations fail at authorization. A webhook configured to synchronize new customer records often receives overprivileged permissions:
These toxic combinations of overprivileged permissions create blast radius problems. When the webhook is compromised, attackers inherit all granted permissions, not just those required for the legitimate integration.
Best practices for webhook authorization include:
Even authenticated webhooks can deliver malicious payloads. Applications must validate and sanitize all webhook data before processing:
Schema Validation: Verify the payload structure matches expected format
{
"event": "customer.created",
"data": {
"email": "user@example.com",
"name": "John Doe"
}
}
Input Sanitization: Strip potentially malicious content (SQL injection attempts, XSS payloads, command injection)
Type Enforcement: Ensure data types match expectations (strings are strings, integers are integers)
Size Limits: Reject oversized payloads that could enable denial-of-service attacks
Static security controls alone cannot protect against webhook abuse. Attackers using stolen credentials will pass authentication checks. Organizations need behavioral detection that identifies anomalies in webhook activity patterns.
Key behavioral indicators include:
Volume Anomalies: Sudden spike in webhook requests (potential data exfiltration or DoS attack)
Timing Deviations: Webhook activity during unusual hours (compromised credentials used by attackers in different time zones)
Source Attribution Changes:
Payload Pattern Changes: Unusual data structures or field values that deviate from historical norms
This behavioral approach aligns with how Obsidian Security detects threats across the SaaS ecosystem. Rather than relying solely on static rules, behavioral analysis identifies the subtle deviations that indicate compromise.
Webhook security extends beyond initial configuration to ongoing governance:
Discovery: Maintain accurate inventory of all active webhooks across your SaaS environment
Documentation: Record webhook purpose, data flows, permissions, and business owner
Review Cadence: Regularly audit webhook configurations for stale integrations with admin permissions
Decommissioning: Promptly disable webhooks when integrations are no longer needed
Rotation: Periodically rotate API keys and shared secrets used for webhook authentication
Organizations that treat webhooks as "set and forget" integrations accumulate security debt. That abandoned webhook configured three years ago for a proof-of-concept project? It still has write access to your production Salesforce instance.
The SaaS delivery model introduces unique webhook security challenges that don't exist in traditional on-premises environments. Understanding these considerations helps security teams adapt their controls for cloud-native architectures.
SaaS applications serve multiple customers from shared infrastructure. Webhook implementations must ensure proper tenant isolation to prevent cross-customer data leakage.
Risks:
Mitigations:
Webhooks inherit the permissions of the account or service account that configured them. This creates transitive trust relationships where Application B gains access to Application A's data through the webhook connection.
Consider this scenario:
This inherited permissions problem mirrors the challenges of OAuth token security, where the authorizing user's permissions flow to the connected application.
Best practices:
The ease of configuring webhooks leads to integration sprawl. Developers and power users can establish webhook connections without IT or security approval, creating shadow integrations that bypass governance processes.
Many organizations discover webhook integrations only when:
This discovery problem stems from webhook configuration happening at the application layer, invisible to network security tools. A developer with Slack admin rights can configure outbound webhooks to external services without triggering any security alerts.
Webhooks depend on API availability at both source and destination. Rate limiting, service disruptions, and quota exhaustion create reliability challenges that have security implications.
Webhook Queuing and Retry Logic:
When destination endpoints are unavailable, webhook sources typically queue failed requests and retry delivery. This creates several risks:
Rate Limit Exploitation:
Attackers can intentionally trigger webhook floods to:
Webhooks transmit data between SaaS applications that may be hosted in different geographic regions. This creates data residency challenges for organizations subject to regulations like GDPR, CCPA, or sector-specific requirements.
Questions security teams must answer:
Many organizations discover cross-border data flows only during compliance audits, when regulators ask for detailed data flow diagrams. The webhook configured to synchronize customer data from your US-hosted CRM to your vendor's EU-hosted analytics platform? That's a cross-border transfer requiring documentation and legal safeguards.
Webhooks represent a critical component of the SaaS supply chain attack surface. When attackers compromise a SaaS vendor, they gain access to:
This access enables several attack techniques:
Webhook Replay Attacks: Attackers capture legitimate webhook requests and replay them with modified payloads, exploiting the trust relationship between applications.
Webhook Injection: Attackers send crafted webhook requests to customer endpoints, leveraging stolen credentials to bypass authentication.
Data Exfiltration: Attackers modify webhook configurations to redirect data flows to attacker-controlled endpoints, creating invisible data leakage channels.
The challenge for security teams is that these attacks leverage legitimate infrastructure and valid credentials. Traditional security tools cannot distinguish between normal webhook activity and attacker abuse. This is where behavioral detection becomes essential; identifying the subtle anomalies in request patterns, payload structures, and source attribution that indicate compromise.
Implementing robust webhook security requires a combination of native SaaS controls, third-party tools, and adherence to emerging standards. Security teams must assemble a layered defense that addresses webhook-specific risks.
Most enterprise SaaS applications provide built-in webhook security features, though their sophistication varies significantly:
Webhook Configuration Auditing:
IP Allowlisting:
Signature Verification:
Limitations: Native controls provide point-in-time visibility within individual applications. They cannot correlate webhook activity across your entire SaaS ecosystem or detect behavioral anomalies that span multiple applications.
Organizations can route webhook traffic through API gateways or dedicated webhook proxy services to centralize security controls:
Benefits:
Implementation Considerations:
Security Information and Event Management (SIEM) platforms can ingest webhook logs for correlation and analysis:
Use Cases:
Challenges:
Traditional security tools struggle with webhook security because they lack context about the changing relationships between SaaS applications. This is where specialized SaaS security platforms provide critical capabilities.
Obsidian Security's Approach to Webhook Security:
Rather than relying on static inventories or point-in-time snapshots, Obsidian uses behavioral analysis to detect webhook anomalies:
Knowledge Graph Correlation: Obsidian's Knowledge Graph maps relationships between users, applications, integrations, and data flows. This enables detection of unusual webhook activity patterns that span multiple applications.
Behavioral Baselines: By establishing normal patterns for webhook volume, timing, and source attribution, Obsidian can identify deviations that indicate compromise.
Non-Human Identity Governance: Webhooks represent non-human identities (service accounts, API keys) that operate independently of user authentication. Obsidian provides visibility and governance for these machine identities across the SaaS ecosystem.
Integration Security: Obsidian detects overprivileged permissions, stale integrations with admin access, and toxic combinations of permissions that create excessive blast radius.
This behavioral approach addresses the fundamental challenge: webhook compromise uses valid credentials and legitimate infrastructure, making it invisible to traditional security controls. Only by understanding normal behavior can security teams detect the subtle anomalies that indicate abuse.
The webhook security landscape is evolving, with emerging standards aimed at improving authentication and authorization:
OAuth 2.0 for Webhooks: Some vendors are implementing OAuth-based webhook authentication, where the webhook source obtains an access token before delivering payloads. This provides stronger authentication than static API keys.
WebSub (formerly PubSubHubbub): A W3C recommendation for webhook-style content distribution with built-in subscription verification and content verification mechanisms.
CloudEvents: A CNCF specification for describing event data in a common format, improving interoperability and enabling better security tooling.
Best Practice Frameworks:
Effective webhook security requires more than tools; it demands a structured program that addresses people, processes, and technology:
Discovery and Inventory:
Risk Assessment:
Governance and Policy:
Monitoring and Detection:
Continuous Improvement:
This programmatic approach ensures webhook security receives ongoing attention rather than being treated as a one-time configuration exercise.
Webhook security represents a critical but often overlooked component of SaaS supply chain security. These automated HTTP callbacks create persistent connections between applications, operating outside traditional authentication controls and creating invisible pathways for attackers to exploit.
The fundamental challenge is that webhooks function as non-human identities authenticated by bearer tokens; API keys and shared secrets that grant full access to whoever possesses them. When a SaaS vendor is breached, attackers gain these credentials and can impersonate legitimate webhook sources, injecting malicious payloads or exfiltrating sensitive data through trusted connections.
Traditional security tools cannot adequately protect against webhook abuse because they lack behavioral context. Firewalls see only encrypted HTTPS traffic to legitimate domains. CASBs cannot inspect webhook payloads without breaking encryption. SSPMs capture static point-in-time configurations but miss the behavioral anomalies that indicate compromise.
Security teams need a different approach; one that combines:
Webhook security cannot be solved through perimeter defenses or traditional identity controls. It requires visibility into the hidden layer between SaaS applications; the integrations, tokens, and service accounts that create the SaaS supply chain attack surface.
Organizations serious about securing their SaaS ecosystems must extend their security programs beyond user identities to encompass the machine identities that power modern integrations. This means treating webhooks not as technical implementation details but as critical security controls requiring governance, monitoring, and behavioral detection.
Next Steps for Security Teams:
The SaaS supply chain will continue to expand, with integrations increasing year over year. Security teams that build robust webhook security programs now will be positioned to manage this growth without accumulating security debt. Those that continue treating webhooks as invisible infrastructure will discover their exposures only when vendor breach notifications arrive.
For organizations seeking to understand their complete SaaS attack surface: including webhooks, OAuth integrations, and other non-human identities; behavioral detection platforms provide the visibility and context that traditional tools cannot deliver. The question is no longer whether your SaaS supply chain will be targeted, but whether you'll detect the attack before it becomes a breach.
In the wake of the Salesloft breach, we’re offering a free risk assessment of your Salesforce environment to help identify potential exposure. Click here to request yours.
Take a breather! In under 6 minutes, our demo breaks down the risks AI agents bring to your SaaS environment and how you can get ahead of them.
We're offering a free AI agent risk assessment—check it out.
The biggest SaaS breach of 2025 started with a compromised third-party app. Attackers then exploited Salesloft-Drift OAuth tokens, which granted them access to hundreds of downstream environments. Obsidian researchers found the blast radius of this supply chain attack was 10x greater than previous incidents, where attackers infiltrated Salesforce directly.
Start in minutes and secure your critical SaaS applications with continuous monitoring and data-driven insights.
.png)
.png)