No. An IP allowlist reduces spoofed traffic, but it only tells you where a request came from, not that the payload is genuine or untampered. Pair it with a webhook secret and signature check, HTTPS, and validation of the event itself.
What each control proves
| Control | What it tells you | What it misses |
|---|---|---|
| IP allowlist | The request came from a listed address | Anything sent through a compromised or shared sender; stale lists |
| Webhook secret and signature | The sender knew the secret and the body was not changed | Replays of an old valid delivery |
| HTTPS | The channel is private in transit | Who sent it |
| Event type and delivery ID checks | The payload is the kind you expect and is new | Whether the content is safe to act on |
GitHub's best practice list includes all of these: use a webhook secret, use HTTPS with SSL verification, allow GitHub's IP addresses, check the event type and action, and use the delivery header to spot replays. It treats the allowlist as one item among several, and notes the list changes, so you fetch it from the meta endpoint and update it periodically.
Why an allowlist alone fails
- Lists go stale. If the provider adds addresses and you do not update, you drop real events. Teams then widen the rule to "allow all", which removes the control.
- Some providers send from large shared ranges. An address in the range does not identify one sender.
- A request that reaches you through a proxy or load balancer may carry a different source address than you expect, so rules need care.
- An allowlist says nothing about replay. A captured valid delivery from an allowed address is still a valid delivery.
A sensible layered setup
- Require HTTPS on the endpoint and leave certificate verification on.
- Set a high-entropy secret on the webhook and keep it in a secrets manager.
- Verify the signature on the raw body before any other processing.
- Check the event type and action. Ignore events you did not subscribe to.
- Store the delivery ID and reject repeats.
- Add the provider's published IP ranges as an extra filter if you can automate updates.
- Respond fast with a 2xx, then do the heavy work in a queue. GitHub advises responding within 10 seconds.
Try it yourself
Click through it at your own pace, or open it full screen. Watch how an API scan reports endpoints by authentication status, which is the same question to ask of every webhook receiver.
Quick check
If I verify the signature, do I still need the allowlist?
It is optional. The signature is the stronger control. An allowlist adds friction for random scanners and keeps noise down, as long as you can keep it current.
Should the secret go in the endpoint URL?
No. GitHub advises keeping sensitive information out of the payload URL. Use the signature header instead.
Safeguard's API security scanning can check your own endpoints for missing authentication. Run the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
