Is the CF-Worker header from worker fetch() reliable?

Developers Workers
#1

I noticed that, when making a fetch() request from within a worker, it sends a CF-Worker header with the eTLD+1 of the host that served the request. I don’t see any documentation on this header…is it reliable and will it be persistent (i.e., not removed in future versions)?

Thanks!

#2

Yes, this header is reliable and is intended to be used for security and anti-abuse purposes. It actually names the Cloudflare zone, which is usually the eTLD+1, but it’s actually possible (though unusual) for Cloudflare zones to be subdomains.

We should definitely document it better, sorry about that.

2 Likes
#3

Thanks, Kenton. Could it be a subdomain if using a 3rd party zone via SSL for SaaS?

#4

The CF-Worker header identifies the zone that owns the worker, regardless of what hostname received the HTTP request that triggered the worker.

#5

Is it normal that it leaks the zone domain? Like if it’s fronted by sub.foo.bar, it reveals foo.bar to the destination host. I feel like it should be something more obscure, like the zone ID itself.

#6

Yes, this is by design.

Providing the domain name to the target server is very useful, not just for abuse defense but also basic debugging and observability (e.g. “Whoa, where’s all this traffic coming from? Oh, that’s our partner example.com, I’ll go ask them about it.”). We also felt that being transparent here would help avoid situations where angry server admins receiving unexplained traffic decide to block the entire Cloudflare Workers platform.

On the other hand, we couldn’t think of any non-abusive use cases where hiding the zone name would be useful. If you have one in mind, though, I’d love to hear about it.

2 Likes