Webhook security and SaaS supply chain risk in 2026

At a glance

What this is: This guide explains why webhooks function as non-human identities in SaaS ecosystems and how compromised credentials, endpoint takeover, and shadow integrations turn them into attack paths.

Why it matters: IAM and NHI teams need visibility into webhook trust relationships because traditional user-centric controls do not govern persistent machine-to-machine access.

By the numbers:

• The average enterprise maintains 47 active webhook endpoints across its SaaS ecosystem, with security teams able to document only 23% of them in their integration inventories.
• The average enterprise maintains 47 active webhook endpoints across its SaaS ecosystem, with security teams able to document only 23% of them in their integration inventories.

👉 Read Obsidian Security's guide to webhook security in SaaS integrations

Context

Webhook security is really SaaS supply chain governance for machine-to-machine data flows. When an application pushes data to another system automatically, the connection inherits trust, permissions, and retention assumptions that are rarely reviewed with the same discipline applied to human access.

That gap matters because webhook traffic often sits outside the normal identity plane. Once an endpoint, shared secret, or API key is exposed, an attacker can replay trusted requests, move laterally across downstream tools, or hide inside integrations that security teams never inventoried.

For IAM and NHI practitioners, the problem is not whether webhooks exist. It is whether the organisation can name every active connection, prove who owns it, and retire it when the business workflow changes.

Key questions

Q: How should security teams inventory webhook integrations across SaaS applications?

A: Start with application admin consoles, source control, procurement records, and cloud logs, then reconcile the results into a single owner-specific inventory. Each entry should include source, destination, auth method, business purpose, data class, and rotation status. If a team cannot name who owns a webhook, it is already a governance gap.

Q: When does webhook security become an IAM and NHI issue instead of an app issue?

A: It becomes an IAM and NHI issue as soon as the integration carries credentials, inherits permissions, or moves sensitive data without user interaction. At that point the webhook is operating as a machine identity with standing authority, so access scope, lifecycle, and revocation all need governance.

Q: What is the difference between webhook security and OAuth token security?

A: OAuth tokens usually represent delegated user consent that can expire or be revoked through identity workflows, while webhooks often rely on persistent shared secrets or signatures attached to automated callbacks. Both are non-human identities, but webhooks more often create silent background trust that is harder to inventory and monitor.

Q: How can organisations reduce the risk of webhook-driven SaaS supply chain attacks?

A: Use least privilege, dedicated service accounts, strong request verification, continuous inventory, and behavioural monitoring together. The goal is to shrink the trust window, detect endpoint drift, and prevent one compromised integration from becoming a downstream compromise across multiple SaaS systems.

Technical breakdown

Why webhook authentication behaves like NHI trust

Webhooks authenticate with bearer tokens, API keys, shared secrets, or HMAC signatures, which means possession often equals authority. That model is closer to machine identity than user authentication because there is no interactive login, no MFA step, and often no user context attached to each request. In practice, the receiving system trusts the caller based on credentials and endpoint metadata, then processes the payload as if it came from a known source. If the secret leaks from code, chat, or a support ticket, the attacker can act as the integration until rotation or revocation occurs.

Practical implication: Treat every webhook credential as an NHI secret with explicit ownership, rotation, and revocation requirements.

How webhook compromise enables SaaS-to-SaaS lateral movement

Webhook compromise becomes dangerous because the trust boundary sits between applications, not within a single tenant. If an attacker obtains a vendor's webhook credentials or gains control of an abandoned endpoint, they can send valid-looking payloads into downstream systems that are already configured to trust the source. This is transitive trust: one compromised integration can trigger actions in multiple connected applications. The risk increases when webhook payloads carry customer data, authorization events, or administrative state changes, because those messages can be used to create records, alter workflows, or mask malicious activity.

Practical implication: Map downstream dependencies for every webhook so a single compromise cannot become a multi-application incident.

Why traditional perimeter tools miss webhook abuse

Firewalls, CASBs, and many SIEM deployments struggle here because webhook traffic is legitimate HTTPS to known services and often encrypted end to end. Static inventories also age poorly because integrations change as teams add, decommission, or retarget endpoints. That leaves a behavioral problem, not just a configuration problem. Security teams need to understand normal delivery rates, source patterns, retry behaviour, and schema changes. Without that baseline, a replayed request, an endpoint takeover, or a sudden burst of retries can look like ordinary application noise instead of an attack.

Practical implication: Build behavioural monitoring for webhook volume, source, and payload drift, not just static configuration review.

Threat narrative

Attacker objective: The attacker wants to turn a trusted integration into an authenticated path for stealthy access, data theft, and downstream compromise.

1. Entry occurs when an attacker steals a webhook API key or takes over an expired destination endpoint that still receives trusted traffic.
2. Escalation follows when the attacker replays legitimate-looking payloads into connected SaaS applications and uses inherited permissions to trigger unwanted actions.
3. Impact occurs when the compromised integration enables data exfiltration, malicious payload injection, or SaaS-to-SaaS lateral movement across downstream environments.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Webhook security is an NHI governance problem disguised as an application feature. The article's core lesson is that integrations create standing machine authority that is usually treated as plumbing, not identity. Once a webhook is configured, it persists across administrative handoffs, tool changes, and vendor incidents. Practitioners should govern webhooks with the same discipline they apply to other non-human identities: ownership, scope, rotation, and retirement.

Webhook compromise widens the identity blast radius because trust is transitive. A single exposed secret can grant access to multiple systems that were never designed to share an identity plane. That is why inventory quality matters as much as secret hygiene. Teams that cannot map source, destination, and business purpose will struggle to contain an incident even when they detect one.

Persistent integrations need behavioural controls, not just configuration controls. Static review catches what exists today, but webhook abuse often appears as a timing, volume, or schema anomaly after the integration has already been trusted. This pushes webhook governance toward continuous monitoring, anomaly baselining, and enforced owner review. The practitioner conclusion is clear: if the integration can move data automatically, it needs runtime oversight.

Webhook sprawl is the early warning signal for shadow NHI risk. The easier it becomes for teams to add integrations without central approval, the more likely the organisation is to accumulate undocumented machine identities. That sprawl weakens auditability and raises the chance that decommissioned endpoints or stale credentials remain live. Practitioners should treat shadow integrations as an identity hygiene problem, not a tooling inconvenience.

From our research:

• The average enterprise maintains 47 active webhook endpoints across its SaaS ecosystem, with security teams able to document only 23% of them in their integration inventories, according to Guide to the Secret Sprawl Challenge.
• From our research: 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of Secrets Sprawl 2026.
• From our research: For teams expanding into agentic workflows, the OWASP NHI Top 10 is the next control lens to apply because integration trust is no longer limited to classic SaaS connectors.

What this signals

Webhook sprawl is a leading indicator that the organisation has already lost precise NHI visibility. The practical issue is not the number of integrations alone, but the fact that undocumented machine identities tend to persist after business workflows change. Teams should expect audit and incident-response questions to become harder, not easier, unless webhook ownership is tied to lifecycle review and decommissioning.

Identity blast radius is now a measurable control objective for SaaS programmes. When a single secret or abandoned endpoint can affect several downstream systems, containment depends on how quickly the organisation can isolate trust paths. Security leaders should align webhook governance with NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10 so runtime monitoring and lifecycle control are treated as one programme.

For practitioners

• Inventory every active webhook Build a complete register of source application, destination endpoint, business owner, payload type, and auth method. Reconcile that inventory against procurement, app admin consoles, and change records so hidden integrations do not sit outside review.
• Replace shared secrets with stronger verification Use HMAC signatures or equivalent request validation where possible, then rotate all webhook credentials on a fixed schedule and after any vendor incident. Apply the same handling discipline used for other NHI secrets.
• Constrain webhook permissions to the minimum path Give webhook service accounts only the permissions needed for the specific workflow, never broader admin access. Separate production and non-production integrations so a proof-of-concept workflow cannot reach sensitive systems.
• Monitor webhook behaviour continuously Baseline normal delivery rates, source IPs, retry patterns, and payload schema changes, then alert on drift. Pair that telemetry with lifecycle guidance from the Guide to the Secret Sprawl Challenge and the OWASP Non-Human Identity Top 10.

Key takeaways

• Webhooks are machine identities with persistent authority, not just integration glue, so they need lifecycle governance.
• The scale problem is already visible, with enterprises documenting only a fraction of active webhook endpoints.
• Teams that inventory, constrain, and monitor webhook trust paths will reduce the blast radius of SaaS supply chain compromise.

Key terms

• Webhook: An automated HTTP callback that sends event data from one application to another when a trigger occurs. In security terms, a webhook is a machine-to-machine trust path that can carry sensitive data and authorization context without a human login step.
• Non-Human Identity: A non-human identity is any credentialed software entity that can authenticate, access resources, or perform actions on its own. In this context, webhooks, service accounts, API keys, tokens, and certificates all require lifecycle controls because they can be abused like user accounts, sometimes more quietly.
• Transitive Trust: Transitive trust is the risk that one system's permissions extend into another system through a shared integration. In SaaS environments, a webhook can inherit the authority of the account that created it, which means compromise in one place can cascade into several downstream systems.
• Shadow Integration: A shadow integration is an undocumented or unmanaged connection between applications that operates outside central governance. These integrations often appear when business teams configure webhooks directly, leaving security teams without clear ownership, data-flow visibility, or retirement controls.

Deepen your knowledge

Webhook security and NHI lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping integrations, secrets, and ownership across SaaS workflows, it is worth exploring.

This post draws on content published by Obsidian Security: What is Webhook Security: Securing SaaS Integrations in 2026. Read the original.