Today’s Lesson
Security for Legal SaaS — Episode 11: Webhook Security and SSRF
When Your Server Becomes the Attacker’s Proxy
Webhooks are how modern SaaS integrations communicate — your e-filing system notifies your case management platform that a submission was accepted, your payment processor confirms a retainer deposit, your e-discovery vendor signals that a production set is ready. Each webhook endpoint is a door you’ve opened in your perimeter. Server-Side Request Forgery (SSRF) exploits that door by tricking your server into making requests to internal resources the attacker cannot reach directly.
Key stat: SSRF entered the OWASP Top 10 in 2021 as a standalone category after years of increasingly severe real-world exploits — including the Capital One breach where SSRF against AWS metadata endpoints exposed 106 million records.
In legal SaaS, the attack surface is particularly dangerous because integrations with courts, regulators, and counterparties are not optional — they are the product. You cannot simply block all outbound requests.
SSRF: Your Server as the Attacker’s Puppet
SSRF occurs when an attacker can influence a URL that your server-side code fetches. The server dutifully makes the request using its own network position — behind your firewall, on your VPC, with access to internal metadata endpoints and private services.
The Attack Pattern
| Step | What Happens |
|---|---|
| 1 | Attacker sends a webhook registration or callback URL pointing to an internal resource |
| 2 | Your server fetches the URL (e.g., validating a webhook, downloading a referenced document) |
| 3 | Internal service responds to your server as if it were a legitimate internal request |
| 4 | Attacker receives the response or observes side effects |
The Capital One breach (2019) demonstrated this precisely — an SSRF vulnerability allowed an attacker to query the AWS Instance Metadata Service (IMDS) at 169.254.169.254, retrieve IAM role credentials, and exfiltrate 106 million customer records from S3.
AWS responded by introducing IMDSv2, which requires a PUT request with a hop-limited token — but your application code must still validate URLs before fetching them.
DNS Rebinding: Bypassing Allowlists
Even if you validate that a URL resolves to a public IP before fetching it, DNS rebinding attacks can defeat this check. The attacker controls a DNS server that returns a public IP on the first lookup (passing your validation) and an internal IP on the second lookup (when your server actually connects).
Mitigation: Resolve the DNS once, pin the IP, validate it is not in RFC 1918/link-local/loopback ranges, and connect to that specific IP with the original hostname in the Host header. Libraries like ssrf-req-filter implement this pattern.
Webhook Signature Verification
Every inbound webhook must prove it came from the expected sender. Without verification, any attacker who discovers your endpoint URL can forge webhook payloads — creating fake payment confirmations, fraudulent filing receipts, or spoofed e-discovery notifications.
The HMAC Pattern
The industry standard is HMAC-SHA256 signature verification, as implemented by GitHub, Stripe, and most modern platforms:
| Component | Purpose |
|---|---|
| Shared secret | Pre-exchanged key between sender and receiver |
| Signature header | HMAC-SHA256(secret, raw_body) sent with each request |
| Timestamp header | When the webhook was generated |
| Replay window | Reject webhooks older than 5 minutes |
Critical implementation detail: Compute the HMAC over the raw request body bytes, not a parsed-and-reserialized version. JSON key reordering, whitespace changes, or encoding differences will produce a different hash. Stripe's documentation explicitly warns about this.
Timestamp Validation and Replay Prevention
Stripe’s webhook security model includes a timestamp in the signed payload. Your verification must:
1. Extract the timestamp from the signature header
2. Reject if the timestamp is more than 5 minutes old (configurable tolerance)
3. Include the timestamp in the HMAC computation so it cannot be modified independently
Without timestamp checks, an attacker who intercepts a valid webhook can replay it indefinitely — triggering duplicate payment confirmations or reprocessing already-handled filings.
Allowlisting Outbound Destinations
When your server makes outbound requests (fetching documents, calling external APIs, delivering webhooks), restrict where it can connect.
Defence in Depth for Outbound Requests
| Layer | Control |
|---|---|
| Application | URL validation — reject private IPs, localhost, metadata endpoints |
| DNS | Pin resolved IPs; reject RFC 1918, 169.254.0.0/16, ::1 |
| Network | Egress firewall rules — allowlist specific CIDR ranges per integration |
| Cloud | VPC egress policies or AWS Security Groups restricting outbound |
For legal integrations specifically, your allowlist is often well-defined: court e-filing endpoints have published IP ranges, payment processors provide webhook IP lists (Stripe publishes theirs), and e-discovery platforms document their callback infrastructure.
Legal Integration Attack Scenarios
E-Filing Systems
Court e-filing integrations (like Tyler Technologies Odyssey) require your system to accept callbacks confirming submission status. An attacker who compromises or impersonates this callback can mark fraudulent filings as “accepted” in your system.
Mitigations: Verify webhook signatures, cross-reference filing IDs against your submission log, implement out-of-band confirmation for critical filings.
Payment Processors
Retainer deposit confirmations arrive via webhooks. Stripe’s documentation on webhook security exists because the consequences of forged payment notifications are direct financial loss.
E-Discovery Platforms
When a production set is ready for download, the e-discovery platform sends a notification with a URL. If that URL is attacker-controlled, your server fetches malicious content or leaks credentials in the request headers.
Practical Hardening Checklist
Implementation checklist: 1. ☐ Validate all webhook signatures using HMAC-SHA256 with constant-time comparison 2. ☐ Reject webhooks with timestamps older than 5 minutes 3. ☐ Maintain idempotency keys to prevent replay attacks 4. ☐ Validate and pin DNS for all outbound fetches — reject private/link-local ranges 5. ☐ Implement egress firewall rules at the network layer 6. ☐ Enable IMDSv2 on all cloud instances 7. ☐ Log all inbound webhooks with source IP, signature validity, and processing outcome 8. ☐ Use OWASP's SSRF Prevention Cheat Sheet as your implementation reference
Testing Your Defences
PortSwigger’s SSRF lab series provides hands-on practice exploiting and defending against SSRF. For webhook testing, tools like Svix’s webhook testing utilities let you simulate signature failures, timestamp manipulation, and replay attacks in a controlled environment.
The OWASP SSRF Prevention Cheat Sheet provides language-specific guidance for URL validation, including edge cases like IPv6-mapped IPv4 addresses and URL parser differentials.
Conclusion
Your webhook endpoints are trust boundaries — they accept data from external systems and trigger internal actions. SSRF turns your server’s network position against you. In legal SaaS, where integrations with courts, payment systems, and opposing counsel are unavoidable, these attack surfaces cannot be eliminated — only hardened through signature verification, URL validation, network controls, and continuous monitoring.
Next episode: Browser Security Headers — where we’ll see how CORS misconfigurations and missing headers turn your client’s browser into an attack vector.