Couldn’t you also avoid rate-limits and such with setting your own X-Forwarded-For header? I guess the site operator should have been a bit more vigilant and used the Cf-Connecting-IP header in that specific case.
You need to block traffic at the origin from anyone except your CDN or proxy, and the CDN or proxy must not accept such headers, they must set them themselves.
Depending on your set-up you may need to use one or both of those headers. For example, you might use CloudFlare for some requests and CloudFront for others, as you may find one or the other to be cheaper or faster for specific content. So you may need to allow both headers at your origin's reverse proxies, but distinguish between which to accept and where to redirect the traffic based on the Virtual Host and request URI.
The server should only accept the header from trusted proxies (like nginx, your load balancer, etc). If #1 is possible, you have a bigger problem of letting the client send any arbitrary IP.
Depending on your set-up you may need to use one or both of those headers. For example, you might use CloudFlare for some requests and CloudFront for others, as you may find one or the other to be cheaper or faster for specific content. So you may need to allow both headers at your origin's reverse proxies, but distinguish between which to accept and where to redirect the traffic based on the Virtual Host and request URI.