Webhook security and DNS rebinding

Webhook destinations must use HTTPS. The Gateway rejects loopback, RFC 1918 private, link-local, cloud-metadata, internal-hostname, and private IPv6 destinations. Redirects are not followed by the Queue consumer, and the destination is checked again immediately before each delivery. localhost and plain HTTP are available only when the deployment explicitly sets WEBHOOK_ALLOW_LOCALHOST=true for local development or tests.

The Queue consumer also performs a just-in-time DNS-over-HTTPS preflight for public hostnames immediately before delivery. It requires successful A and AAAA lookups and rejects any private, loopback, link-local, metadata, documentation, multicast, or otherwise reserved answer. URLs containing credentials or nonstandard ports are rejected as well. DNS failures therefore fail closed and the message is retried rather than delivered.

This is still not an absolute defense against DNS rebinding. A DNS answer can change after the preflight and before the platform opens the connection. A URL parser and an application-level DNS check cannot pin an arbitrary external hostname in Workers: Cloudflare's resolveOverride is restricted to hosts in the same zone, and Workers do not support direct IP URL fetches.

Production deployments must configure WEBHOOK_ALLOWED_HOSTS with exact customer webhook hostnames and add an egress-layer control. Options include an approved-host allowlist, an outbound proxy or API gateway that validates the resolved IP before connecting, or Cloudflare/network egress policy that blocks private, loopback, link-local, and metadata ranges. The Worker checks add a layer of defense; egress controls provide the final DNS-rebinding boundary.