How to Secure Your Webhooks in 2026

Your webhook endpoint is a publicly reachable HTTP endpoint that accepts data from the internet. If you're not thinking carefully about security, you're betting that nobody will try to abuse it.

This isn't paranoia — webhook endpoints get probed and spoofed regularly. A fake "payment succeeded" event that your handler processes as real can be a very expensive mistake. Here's how to make sure that doesn't happen.

Step 1: Verify Signatures

Every major webhook provider signs their payloads with a shared secret. Stripe uses HMAC-SHA256. GitHub uses the same. Verifying the signature is the fundamental security check — it proves the request actually came from the service you think it did, not from someone who found your endpoint URL.

The basic pattern:

var signature = Request.Headers["Stripe-Signature"];
var webhookSecret = _configuration["Stripe:WebhookSecret"];

try
{
    var stripeEvent = EventUtility.ConstructEvent(
        requestBody,
        signature,
        webhookSecret
    );
    // process event
}
catch (StripeException)
{
    return BadRequest("Invalid signature");
}

Do not skip this check. Do not disable it because it's annoying in development (use ngrok with a real endpoint and a test webhook secret instead).

One caveat: signature verification only proves origin. It doesn't prevent replay attacks where someone captures a valid signed request and resends it multiple times. For critical operations, combine signature verification with idempotency checking (store the event ID and reject duplicates).

Step 2: IP Allowlisting

Major webhook providers publish the IP ranges they send from. If you can restrict your webhook endpoint to only accept traffic from those IPs, you add a network-layer defense that blocks everything else before it even reaches your signature verification code.

Stripe publishes their IP list at their official documentation. GitHub, Shopify, and others do the same.

The downside of maintaining IP allowlists manually is that they change. Providers add new IP ranges, and if you hardcode the list, you'll eventually block legitimate traffic when they add a new egress IP.

Bluejay Relay handles this automatically — you configure IP allowlists per integration in the platform, and you can update them without deploying code. IP allowlisting with CIDR support is available on every tier as a configurable security control.

Step 3: Validate Payload Structure

Even after verifying the signature, validate that the payload has the structure you expect before processing it.

A webhook from Stripe will have a type field and a data.object with consistent properties for each event type. If you receive a payment_intent.succeeded event with a missing amount field, something is wrong — either the API version changed or someone is sending a crafted payload.

Define schemas for the event types you care about and reject anything that doesn't match. This is especially important for events that trigger financial or access-control logic.

If you're validating JSON schemas in a .NET project:

if (!TryValidatePaymentIntentSchema(payload, out var errors))
{
    _logger.LogWarning("Webhook payload failed validation: {Errors}", errors);
    return BadRequest();
}

Step 4: Rate Limiting Your Endpoint

Your webhook endpoint should have rate limiting, full stop. A burst of requests — whether from a misconfigured sender or a deliberate attack — can overwhelm your handler and cause cascading failures.

The right rate limit depends on your expected volume. For most Stripe integrations, a few hundred requests per minute is more than enough. Anything above that is probably abnormal and worth throttling.

Bluejay Relay applies configurable rate limits per integration (on every tier), so your application endpoint sees a smoothed, controlled delivery rate regardless of what the upstream service does.

Step 5: Don't Trust Embedded URLs or Redirects

If your webhook payload includes URLs that your handler fetches (say, a download link for a file uploaded by a user), validate those URLs before following them. SSRF (Server-Side Request Forgery) via webhook payloads is a real attack class.

Allowlist the domains your handler is permitted to fetch from, and reject anything else.

Step 6: Use HTTPS, Obviously

Your webhook endpoint must use HTTPS with a valid certificate. All major webhook providers enforce this. Beyond compliance, an HTTP endpoint transmits your payload and any response over an unencrypted connection that can be intercepted on the network path.

If you're in a dev environment without a valid cert, use something like Cloudflare Tunnel or ngrok to get a valid HTTPS endpoint pointing at your local server.

Putting It Together

Security in layers is the goal: signature verification at the application level, IP allowlisting at the network level, payload schema validation in your business logic, rate limiting on the infrastructure layer, and HTTPS as the transport foundation.

Bluejay Relay handles the network-layer defenses (IP allowlisting, rate limiting) and gives you a permanent log of every request with the raw payload — so if something suspicious does get through, you have the forensic data to understand it.

---

Try Bluejay Relay free and configure your first secure webhook integration today.