Unsigned Webhook Requests: What to Do

Updated 5 November 2026 · Standard formula, shown below

When a webhook provider does not sign requests, you cannot verify that a request actually came from that provider, so you must treat every delivery as untrusted input and validate it through other means, or stop using the webhook until a signature scheme is added. The safest immediate step is to reject the webhook entirely and switch to a pull-based integration, because any fix you build on an unsigned channel is still vulnerable to forgery. If you must keep the webhook, you can add your own security layer, but you need to understand exactly what it can and cannot protect.

Why Signatures Matter in Webhooks

Webhooks are HTTP callbacks: the provider sends a POST request to your endpoint when an event happens. A signature (usually an HMAC hash of the payload with a shared secret) proves two things: the request came from someone who knows the secret, and the payload was not altered in transit. Without it, an attacker who can guess your endpoint URL can send fake events, and a network attacker can modify a legitimate request. Even if your endpoint is on a private network or uses a hard-to-guess URL, that is security by obscurity, not a real control.

Signed webhooks are the industry baseline. Stripe, GitHub, and most major APIs sign their webhooks with an HMAC-SHA256 header. If a provider does not, they are offloading the security problem to you, and you have to decide whether that risk is acceptable for your use case.What You Can Verify Without a Signature

Without a cryptographic signature, you can still check a few things, but none of them prove authenticity:

Source IP address: you can allowlist the provider’s published IP ranges, but IPs can be spoofed at the TCP level only if you do not complete the handshake, and providers often change ranges without notice.
User-Agent or custom header: these are trivially spoofed and provide no security.
Payload structure: you can check that required fields exist and match expected types, but an attacker can craft a valid-looking payload.
Timing or sequence numbers: if the provider includes a monotonically increasing ID, you can reject duplicates, but you cannot prove the sender.

These checks are worth doing as defense in depth, but they do not replace a signature. Treat them as basic hygiene, not as authentication.

Your Options, Ranked by Safety

Here are the realistic paths, from most to least secure:

Stop using the webhook. Poll the provider’s API on a schedule instead. This is the only fully secure option if the provider will not add signatures. You lose real-time delivery, but you gain verifiable data.
Ask the provider to sign. Many providers will add a signature if enough customers request it. It is a small change on their side and a big security win for you.
Add your own signature at the source. If you control the sending system (for example, an internal service), you can wrap the webhook with your own HMAC. This only works when you control both ends.
Accept the risk with compensating controls. Use a secret URL, allowlist IPs, and validate payloads, but understand that an attacker who can guess the URL or spoof an IP can still forge events.

Option 1 is the only one that gives you real security. Options 3 and 4 are partial mitigations.

How to Build a Pull-Based Fallback

If you decide to drop the webhook, you need a reliable polling mechanism. The general pattern:

Determine the provider’s API endpoint that lists events or resources you care about.
Store the timestamp or ID of the last successfully processed event.
Poll at a reasonable interval (every minute, every hour, depending on your needs) and fetch only new items.
Process each item idempotently, so that re-fetching the same event does not cause duplicates.

This approach is more work, but it gives you a clear audit trail: you know exactly what you fetched and when. You also avoid the risk of a forged webhook triggering actions in your system.

If You Must Keep the Unsigned Webhook

If you cannot switch to polling, you can reduce the risk with a layered approach:

Use a random, unguessable URL per integration (e.g., https://yourapp.com/webhooks/8f3a9c...). This is not authentication, but it raises the bar for blind attacks.
Allowlist the provider’s IP ranges at your firewall or load balancer. Check the provider’s documentation for the current list and update it regularly.
Validate the payload schema strictly. Reject anything that does not match exactly what you expect.
Require a shared secret in a custom header, even if the provider does not sign the body. This is weak, but it filters out casual attackers.
Log every request with full headers and body hash, so you can audit after an incident.

None of these make the webhook secure, but they make it harder to exploit. Document that this is a known risk.

Common Misconceptions

“HTTPS is enough.” HTTPS encrypts data in transit, but it does not authenticate the sender. Anyone can send a POST to your endpoint over HTTPS.

“A secret URL is secure.” URLs end up in logs, browser history, and referrer headers. They are not secrets.

“We can just check the payload.” An attacker can craft a payload that passes your schema checks. Schema validation is not authentication.

“The provider is trustworthy, so it is fine.” The risk is not the provider, it is an attacker impersonating the provider. Trust does not stop forgery.

Frequently Asked Questions

Can I add a signature myself on the receiving end?

No. A signature must be added by the sender using a secret you both share. If you add it on your side, you are only signing your own assumption that the request is legitimate, which does not prove anything.

What if the provider signs only some requests?

Treat unsigned requests as untrusted. Reject them or process them with the same caution as if no signing existed. Do not assume a partial signature scheme is a mistake; it may be intentional.

Is it okay to use a webhook if the data is not sensitive?

Even non-sensitive data can be used to trigger actions. A forged “user deleted” event could delete a legitimate account. The risk depends on what your webhook handler does, not just what data it carries.

How do I convince my provider to add signatures?

Contact their support or developer relations team. Reference the security best practices from major platforms (like Stripe or GitHub) and explain the specific risk to your integration. Customer demand is often what drives such changes.

What is the difference between a webhook signature and an API key?

An API key is used when you call the provider’s API; it authenticates you to them. A webhook signature authenticates the provider to you. They are different directions of trust and cannot replace each other.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.