Many projects use Cloudflare as their Web Application Firewall, DDoS Guard, and Crawling Protection rolled into one. This all falls apart if an attacker can expose your server’s real IP address behind Cloudflare.

Quick Note in the Beginning: You should generally not trust in obscurity only. Make sure to configure your server’s firewall to only allow connections to Cloudflare, and to reject connection attempts that don’t match your known domains.

Attack Surface

Once the server’s Host IP is known to an attacker, they can work on circumventing the protection Cloudflare offers.

The most simple form would be pointing DDoS attacks directly against the origin server, fully circumventing Cloudflare. In extreme cases, this could simply saturate the upstream, even with a correctly configured firewall.

Something far more insidious though is that, by circumventing Cloudflare, attackers can forge the trusted Cookies used by Cloudflare. By manually binding your domain to the Origin IP instead of the Cloudflare Endpoint, an attacker has full control over the request that reaches your application. They could forge any of the CF-* Headers and thus e.g. execute actions under a forged IP address.

Attackers will also stop being bound by any rate limits or other access controls set inside Cloudflare!

Firewall Only is not Enough

I have seen attacks in the wild that managed to not only hit the Origin server through Cloudflare, but actually abused Cloudflare itself to amplify the attack. The Origin firewall did not prevent this!

This was cleverly done by the attacker registering a domain under their control with Cloudflare, and then pointing that domain at the victim Origin server. This way, all malicious requests still are coming from Cloudflare IPs, while the attacker has full control over any WAF settings.

How Attackers Find Your IP

Domain Crawling

One of the easiest, most-forward ways attackers find the Origin IP is by brute-forcing (or otherwise crawling) different subdomains, until they find one that still points directly to Origin. Not sophisticated, but effective.

→ make sure none of your subdomains point directly at Origin

E-Mails

Another common culprit of exposed Origin IPs are e-mails. If your application server is also your mail server, the IP will be exposed in any outbound e-mail.

But even if you use third-party-providers and Mail-as-a-Service-tools, those can still expose your IP. Many of these platforms will add custom headers like X-Originating-IP, X-Forwarded-For, or X-Sender-IP that contain the IP address of the machine making the request. If your application server makes direct requests to any mailing tool, this can give an attacker the information needed to circumvent Cloudflare.

→ use a separate microservice or a proxy for sending emails or configure your mailing tool to omit IPs

Push Notifications

More obscure, but I have seen this happen in the wild.

When you sign up for push notifications, a bunch of requests are fired up behind the scenes:

[Browser asks for Permission] → [Browser registers a Service Worker] → [Browser creates a Subscription with external Push Service] → [Browser sends Subscription including Push Service Endpoint to Your Server] → [Your Server sends Push Notifications to the Push Service Endpoint]

An attacker can thus run their own endpoint, disguised as a Push Service, and thus get your server’s Origin IP simply by signing up to receive notifications.

→ same solution as above, use microservice or proxy

Any Other External Request

Same principle holds true for any external request made by your app based on user input. Fetching Open Graph data (og:image etc) is another common culprit, but, depending on your app, there might be more.

It’s your job to keep your server in check and avoid SSRF attacks. Outbound firewall rules might be cumbersome, but can pay off in the long term.