The problem is that CloudFlare encourages a fundamentally insecure architecture. CDN should be used to host static files on a separate, cookie-less subdomain. With such architecture consequences of any data leak from a shared CDN infrastructure are limited.
With CloudFlare all the requests are passed through the CDN. With dynamic, authenticated requests the benefits of this are dubious. The responses can't be cached anyway, an additional HTTP(S)-level hop is required for each request (and many additional IP-level hops). The drawbacks are now obvious: sensitive, unencrypted data of thousands of different sites resides in the same, not isolated, shared process memory. With such architecture we will always be one C pointer manipulation bug away from another leak.
The reason CloudFlare encourages this is because it isn't meant for use as a traditional CDN - they're not a CDN at all really. You don't upload content to them. They're meant as a cache and anti-DDoS proxy more than anything else.
Look at what happens when anyone gets hit with a large scale DDoS attack these days, the first thing people will tell them, myself included is "CloudFlare". How do you handle a massive spike in load on a tiny, usually empty server? CloudFlare is the go-to tool for this purpose, especially for people who can't afford to pay Akamai, BlackLotus, Amazon or others. And they're impressively cheap for small businesses too. You can't hide from a DDoS attack or save your tiny DigitalOcean box if your web server isn't hidden away behind a service like this.
I have nothing against CloudFlare, they've proven themselves extremely trustworthy in many ways and even in handling of past security issues they've been very responsible. But this time that's not the case - the downplaying of the issue is really damaging their reputation in my eyes. I'm a paying customer and I'm quite disappointed to see this.
> They're meant as a cache and anti-DDoS proxy more than anything else
You can't cache responses to authenticated requests, so in case of DDoS attack against an HTTP end point that requires authentication the best CloudFlare can do to safe the back-end is to drop requests, which makes the attack successful. I really can't see benefits of passing authenticated traffic through CloudFlare.
That assumes all users who are performing the attack are authenticated - an extremely unlikely scenario. All said users would also have to be able to pass a captcha which gets engaged in the case that a site is under active attack.
> the best CloudFlare can do to safe the back-end is to drop requests, which makes the attack successful
It can also drop the attack requests, which is generally not from authenticated users, and pass the real traffic to the backend.
Only in the case of real user, authenticated traffic is CloudFlare not a solution. In cases of high unauthenticated user or high fake user traffic or in cases of attacks not operating on HTTP at all, CloudFlare will solve the problem perfectly. Some of the nastiest attacks, like reflection attacks, don't even touch HTTP at all but will quickly knock most servers offline - even lead many server providers to nullroute you to protect their other customers. It'll also get you out in cases of high real user, unauthenticated traffic - like being posted on HN, reddit, etc.
You aren't typically DDoSed by your authenticated users. Cloudflare can validate authentication tokens at the edge; they also have a feature, Railgun, that can potentially cache portions of those authenticated responses. (No affiliation to Cloudflare, btw)
You can cache authed requests. I'm not sure cloudflare supports it, but it's very common.
Even without caching, it's useful to run traffic through frontend servers that are close to users. Terminating SSL as close to visitors as possible speeds things up. Getting visitors off their ISP network and on to quality backhaul helps too.
With CloudFlare all the requests are passed through the CDN. With dynamic, authenticated requests the benefits of this are dubious. The responses can't be cached anyway, an additional HTTP(S)-level hop is required for each request (and many additional IP-level hops). The drawbacks are now obvious: sensitive, unencrypted data of thousands of different sites resides in the same, not isolated, shared process memory. With such architecture we will always be one C pointer manipulation bug away from another leak.