Webhooks involve opening a public endpoint and trusting data from external services. Without proper safeguards, you risk data corruption, unauthorized actions, or attackers using your relay as a springboard for internal network attacks.
This guide covers the security essentials and how Hookpipe handles each one.
Server-Side Request Forgery (SSRF) occurs when an attacker tricks your system into making requests to internal resources — metadata services, databases, admin panels. If your webhook relay doesn't validate destination URLs, it becomes an attack proxy.
Hookpipe validates every destination URL before forwarding. The following are blocked:
If you try to create a hook pointing to any of these, Hookpipe returns a 400 error:
{
"success": false,
"error": "destinationUrl cannot point to private or internal network addresses"
}
The API you use to create and manage hooks must be locked down. If an attacker steals your API key, they can reconfigure your hooks to route data anywhere.
API key authentication is required for all management operations. Receiving webhooks is public, but modifying your configuration isn't.
Key storage: API keys are hashed with SHA-256 before storage. The raw key is shown only once at creation time.
curl -X POST https://hookpipe.app/api/hooks \
-H "Authorization: Bearer hp_live_abc123..." \
-H "Content-Type: application/json" \
-d '{"name": "my-hook", "destinationUrl": "https://example.com/hook"}'
Without a valid Bearer token, you get a 401:
{"success": false, "error": "Unauthorized"}
Never trust a webhook payload blindly. Validate that it matches your expected schema before processing. Malformed or malicious payloads can crash your handlers or inject unexpected data.
Use Hookpipe's filters to reject invalid payloads before they reach your server:
{
"filters": [
{ "field": "type", "operator": "exists" },
{ "field": "data.object.id", "operator": "exists" }
]
}
Payloads that fail all filters return 200 to the sender (no retry) but aren't forwarded to your destination.
If your server is down during a security update or maintenance window, missed webhooks mean lost data. Inconsistent state can lead to authorization bugs, stale permissions, or failed security checks.
Every delivery is retried automatically with exponential backoff:
If all retries fail, the payload is stored for 7 days (30 days on Pro). You can inspect what failed and replay it manually:
curl -X POST https://hookpipe.app/api/hooks/HOOK_ID/payloads/PAYLOAD_ID/replay \
-H "Authorization: Bearer hp_live_abc123..."
Testing webhooks against local development environments often means exposing localhost via a tunnel (ngrok, cloudflared). Leaving these tunnels open longer than necessary is a risk.
Hookpipe's inspection and replay lets you receive real webhooks safely, examine the payload in your dashboard, and replay to your local environment on demand:
# List recent payloads
curl https://hookpipe.app/api/hooks/HOOK_ID/payloads \
-H "Authorization: Bearer hp_live_abc123..."
# Get a specific payload with raw and transformed bodies
curl https://hookpipe.app/api/hooks/HOOK_ID/payloads/PAYLOAD_ID \
-H "Authorization: Bearer hp_live_abc123..."
Hookpipe handles the security fundamentals so you can focus on your application.