SaaS outbound webhook security: prevent SSRF in customer endpoints
Safely deliver SaaS webhooks to customer URLs with destination validation, controlled egress, tenant-scoped secrets, bounded retries and SSRF tests.
In this guide
How do you prevent SSRF in SaaS outbound webhooks?
An outbound webhook makes your service connect to a URL configured by a customer, so a malicious or compromised tenant can try to make the delivery worker reach internal systems. Treat every destination as untrusted. Validate it when saved and again when connecting, restrict network egress, and make sure one tenant's endpoint or secret cannot be used by another tenant. This guide focuses on your service sending callbacks; incoming signature and retry design is covered separately.
Accept only the URL forms your product needs
Require HTTPS unless an explicitly approved integration has a documented exception. Reject credentials embedded in URLs, unsupported schemes, control characters, ambiguous encodings and unexpected ports. Parse with a maintained URL library, normalize the host once, and do not use a loose substring or suffix check such as 'ends with trusted.com' as an allowlist.
Block private and special-use destinations at connection time
Deny loopback, private, link-local, multicast, reserved and cloud-metadata addresses for both IPv4 and IPv6. Resolve DNS and validate all returned addresses, but account for DNS rebinding: the address used by the actual connection must still satisfy policy. A controlled egress proxy or network policy can add a second boundary; application checks alone are not enough.
Control redirects and the full delivery request
Disable automatic redirects where possible. If redirects are part of the product, validate every redirect target and hop under the same policy before following it. Set connection and total timeouts, cap response size, constrain methods and headers, and never forward internal authorization headers or cloud credentials to a customer-controlled host.
| Tenant and endpoint ID | Scheme/port policy | DNS and egress checks | Secrets and payload scope | Timeout/retry/test owner |
|---|---|---|---|---|
| Billing event endpoint | ||||
| Customer automation | ||||
| Disabled or removed URL |
How should webhook credentials and tenant data be protected?
Use a separate signing secret for each tenant endpoint
Generate high-entropy secrets on the server, show them only through a controlled setup flow, and store them in a protected secret store. Sign the exact body and timestamp with a documented algorithm such as HMAC; support rotation with a short overlap period and revoke the old secret after confirmation. Do not put the secret in the endpoint URL.
Send the minimum event payload and bind each delivery to a tenant
Include only fields needed to notify the customer; prefer stable object IDs and a fetch path the customer is already authorized to use over copying entire records, credentials or sensitive personal data into the event. Keep endpoint ownership and event subscriptions attached to a tenant, and re-check that association when a queued delivery executes.
Keep retries bounded and make deliveries observable
Use a delivery ID and event ID so recipients can deduplicate. Apply capped exponential backoff, a maximum retry age and a dead-letter or pause state. Let an administrator disable an endpoint immediately, and ensure a retry cannot silently use a newly reassigned tenant URL or another tenant's secret. Record response class and latency without logging full payloads or secrets.
Which SSRF and tenant-isolation tests should you run?
Test address and URL parsing edge cases safely
In a controlled test environment, cover IPv4 and IPv6 loopback, private, link-local and metadata addresses, encoded hostnames, alternate numeric IP forms, DNS answers that change, and mixed public/private results. Test disallowed schemes, user-info, nonstandard ports and redirects to blocked destinations without probing systems you do not own.
Test cross-tenant endpoint and secret substitution
Create endpoints for tenants A and B, enqueue a delivery for A, then change or remove B's endpoint and rotate secrets while the job is queued. Verify each attempt resolves the persisted endpoint ID and tenant relationship, never a client-supplied URL or shared global secret. Include retry and dead-letter replay cases.
Exercise failures and verify safe worker capacity
Return slow responses, oversized bodies, connection resets, redirect loops and repeated server errors. Confirm delivery workers enforce timeouts, response limits, concurrency caps and retry budgets so one tenant cannot starve other work. Alert on blocked internal destinations, high failure rates and unusual endpoint churn.
SaaS outbound webhook security FAQs
Is checking a webhook URL only when the customer saves it enough?
No. DNS can change between validation and delivery. Enforce destination rules at connection time too, ideally with restricted network egress as an independent control.
Can a webhook worker follow customer endpoint redirects?
Only if that behavior is necessary and every redirect hop is revalidated against the same scheme, address and egress policy. Otherwise disable redirects to avoid turning a public endpoint into a path to an internal one.
Should all tenants share one webhook signing secret?
No. Use endpoint- or tenant-scoped secrets so one customer cannot forge another customer's delivery. Support rotation and revocation and keep secrets out of URLs, logs and error messages.
Does signing a webhook prevent SSRF?
No. A signature helps the recipient verify a message from your service. It does not restrict where your delivery worker connects; destination validation and egress controls address that separate risk.
Related practical guides
Related issue guides
Sources and publication record
Draft prepared 27 September 2026; engineering, security and editorial review pending · Sources checked .
- OWASP Server-Side Request Forgery Prevention Cheat SheetOWASP Foundation
- OWASP Web Service Security Cheat SheetOWASP Foundation
- OWASP REST Security Cheat SheetOWASP Foundation
- IETF RFC 2104: HMAC keyed-hashing for message authenticationInternet Engineering Task Force
- GitHub Docs: Validating webhook deliveriesGitHub
- GitHub Docs: Best practices for using webhooksGitHub
- AWS SaaS Lens: Preventing cross-tenant accessAmazon Web Services
- AWS SaaS Lens: Testing multi-tenant SaaS reliabilityAmazon Web Services
- Amazon SQS Security Best PracticesAmazon Web Services
- OWASP Cheat Sheet: AuthorizationOWASP Foundation
- OWASP Cheat Sheet: LoggingOWASP Foundation
- Digital Personal Data Protection Act, 2023Government of India, India Code