Webhook security: signature verification & replay protection
A plain-language guide to webhook security for small businesses: verify signatures, stop replay attacks, and let only genuine events reach your CRM.
Every integration you switch on adds a small door to the back of your business. A payment confirmation, a new order from your online shop, a form submission, a shipping update — these arrive as webhooks, tiny automated messages one system sends to another the moment something happens. They are wonderfully useful, and also the part of your setup most owners never think about. That is exactly why webhook security deserves a plain-language conversation.
This article explains, without drowning you in code, how to make sure the messages hitting your systems are genuine: what signature verification is, how a shared secret and HMAC prove who sent a request, and why a timestamp and a little memory stop attackers from replaying an old message. The goal is not to turn you into an engineer, but to help you ask your CRM or developer the right two or three questions.
What a webhook really is
Picture a webhook as an automatic phone call between two apps. When a customer pays, your payment provider "calls" your CRM and says: order 4471 is paid. Your CRM answers, records the payment, and maybe fires off a thank-you message. The whole point is speed — the update lands in seconds, with nobody checking a dashboard.
The catch is that this call arrives at a public address — a URL sitting on the open internet. Anyone who learns it can dial it too. And unlike a person on the phone, your systems cannot "hear" whether the caller sounds right; a webhook is just text arriving at a door. Without a way to check who sent it, your CRM will happily believe a stranger.
The same door that receives a genuine order from your online shop connected to your CRM can, if left open, receive a fake one.
The real risk: anyone who knows the URL can knock
Let us be honest about the threat, because fear-mongering helps no one. Nobody is likely to target a two-person real-estate office by name. But webhook URLs leak in ordinary ways: a screenshot in a support chat, a link pasted into public code, a browser extension, an old employee's laptop. Once the address is out, a script can send whatever it likes.
What could a fake message do? It depends on what your webhook triggers. A forged "payment received" could mark an unpaid invoice as settled and ship goods for free. A bogus "new lead" could flood your pipeline with junk. None of this requires a genius hacker — just an open door and a guess about the message format.
A webhook without verification is a doorbell anyone can press, wired to something that actually matters.
Signature verification, without the math
Here is the elegant part. You do not stop strangers by hiding the address — addresses always leak. You stop them by making every genuine message carry a seal only the real sender can produce. That seal is a signature, and the usual method behind it is HMAC.
Think of it as a wax seal pressed from a stamp that only two people own. When you set up a webhook, you and the sender agree on a shared secret — a long, random password that never travels across the internet in plain view. For every message, the sender mixes the content with that secret to produce a short fingerprint, and attaches it to the request. Your side mixes the same message with the same secret and produces its own fingerprint. If the two match, the message is genuine and untouched. If they differ by a single character, you throw it away.
Two things make this strong. First, the secret is never sent, so an eavesdropper cannot copy it. Second, the fingerprint depends on the exact content, so if anyone changes even one digit of the amount, the seal breaks. You do not need to understand the cryptography to insist on it — only to confirm that your system checks the signature before trusting a message, and rejects anything that fails.
Why a valid signature still is not enough: replay attacks
Now the subtle problem. Imagine an attacker cannot forge a seal, but manages to capture one genuine, correctly signed message — a real "payment received" — as it flies past. What stops them from sending that same message again, ten times, an hour later? The signature is perfectly valid, because it is real. This is a replay attack, and signatures alone do not prevent it.
The fix is to give every message a sense of time and identity. Two simple habits do most of the work:
- Timestamps with a short window. The sender stamps each request with the current time and folds it into what gets signed. Your side rejects anything older than a few minutes, so a captured message goes stale fast — like a cinema ticket for a show that already ended.
- Remember what you have already seen. Every event carries a unique ID. Your system notes the IDs it has processed and refuses to act on the same one twice, so even a fresh-looking replay gets caught.
Together these are called replay protection, turning a valid-forever message into one that is good only once, and only for a moment. Most serious webhook providers already send a timestamp and an event ID; the job is making sure your side actually checks them.
A short checklist for locking the door
You do not need all of this on day one, but a mature setup has most of it. Here is what "secure enough" tends to look like for a small business:
- Always use HTTPS. The address your webhook lives at should start with https, so the message is encrypted on its way to you and cannot be read or altered in transit.
- Verify the signature every time. No exceptions, no "we will add it later." An endpoint that skips the check is the whole vulnerability.
- Enforce a timestamp window and track event IDs. This is your replay protection, and it costs almost nothing once set up.
- Keep the secret secret. Store it where passwords live, never in a screenshot, a chat message, or public code. Rotate it if anyone who knew it leaves.
- Return fast, act carefully. Acknowledge the message quickly, but do the real work — shipping, refunds — only after verification passes.
Close the back door on your integrations
Rocketly verifies signed webhooks and blocks replays, so only genuine events reach your CRM.
See how Rocketly secures integrationsWhen this is overkill — and when it absolutely is not
To be honest, not every webhook needs a fortress. If a message only updates an internal dashboard nobody acts on automatically, a leaked fake costs little more than a confusing chart, and hand-building cryptographic checks for it is a poor trade.
The line to watch is simple: does the webhook trigger money, inventory, or messages to customers? A "payment received" that releases goods, a "new order" that reserves stock, a trigger that texts your whole customer list — those deserve full verification and replay protection, without debate. When real consequences sit on the other end of the door, the lock is not optional.
If you are weighing a native integration against a third-party tool, or comparing automation platforms like Zapier and Make, security handling is a fair way to judge them. A good platform makes verification the default, not a setting you must discover.
What a well-behaved CRM does for you
The reassuring news for a non-technical owner: most of this should be invisible. You should not be computing fingerprints by hand. When your web form feeds leads into your CRM, or a delivery update flows in from your carrier, the platform ought to verify each message, reject stale or duplicate ones, and simply not tell you about the junk it quietly refused.
So the practical move is not to learn cryptography. It is to ask three questions of whatever tool receives your webhooks: Do you verify signatures on every event? Do you reject old or repeated messages? And can I rotate the secret myself if it leaks? Clear answers mean the door is locked. Vague ones are worth a closer look, especially before you wire the webhook to anything that keeps two systems aligned with a proper two-way data sync.
Frequently asked questions
Is a hard-to-guess webhook URL enough on its own?
No. A long, random URL raises the bar slightly, but addresses leak through screenshots, logs, and shared code. Treat the URL as public and rely on signature verification, not secrecy.
What is the difference between a signature and a password?
A password proves who you are once, at login. A signature proves that this specific message came from the real sender and was not altered — it is recomputed for every single request, so a stolen old one is of limited use.
Do I need replay protection if I already verify signatures?
Yes, if the webhook triggers real consequences. A signature confirms a message is authentic, but a captured authentic message can be resent. Timestamps and remembered event IDs make sure a genuine message only works once.
Who creates the shared secret — me or the sender?
Usually the sending service generates it and shows it to you once when you set up the webhook. You store it safely on your side. If it ever leaks, you rotate it, which simply invalidates every message signed with the old one.
Webhooks are the quiet machinery that makes modern automation feel effortless, which is precisely why they earn so little attention until something breaks. You do not need to master cryptography to be responsible here — only to treat every incoming message as a claim to be checked, insist on signature verification, add replay protection wherever money or customers are involved, and keep your secret genuinely secret. Do that, and the convenience of webhooks arrives without the open back door. A CRM like Rocketly can handle the checking for you, so only real events reach your pipeline, and you get back to running the business instead of guarding the doorway.