Putting Cloudflare in front of your origin is not "adding a security feature." It changes where your trust boundary lives. Before, your load balancer answered the public internet directly and your security controls sat inside your VPC. After, a globally distributed reverse proxy terminates every connection, inspects it, and only then decides whether to talk to your origin at all. That shift is powerful and it is also easy to half-configure into a false sense of safety. This piece is about the mechanisms — what actually changes, and where the sharp edges are.
What a reverse proxy actually changes
When Cloudflare proxies a hostname (the orange-cloud DNS record), the public DNS answer points at Cloudflare's anycast IPs, not yours. TLS is terminated at the edge PoP nearest the client, the request is decrypted and inspected, and a second connection is made from Cloudflare to your origin. Your origin's job narrows to "answer requests from Cloudflare." Everything hostile — every scan, every flood, every injection attempt — hits the proxy first.
The immediate consequence is that inspection and mitigation happen off your infrastructure, at a network with the capacity to absorb volumetric attacks that would flatten a single ALB. The subtler consequence is that this only holds if an attacker can't skip the proxy and hit your origin directly. Hold that thought; it is the failure mode that undoes everything else.
WAF: managed rulesets versus custom rules
Cloudflare's WAF runs in two layers that solve different problems.
The managed rulesets are the curated defenses: the Cloudflare Managed Ruleset for broad known-exploit coverage, and an OWASP-style core ruleset that scores requests against signature families (SQLi, XSS, traversal, and so on) and blocks once a request's cumulative anomaly score crosses a threshold you set. You deploy these as-is and mostly tune sensitivity and exclusions. They are your coverage against the internet-wide background radiation of automated exploitation, and they update without you.
Custom rules are where you encode knowledge the vendor can't have. They are expressions in a Wireshark-like filter language over request fields — http.request.uri.path, ip.geoip.country, http.request.headers, cf.threat_score — combined with an action. "Challenge any POST to /admin that isn't from our office ASN." "Block requests to the legacy API path that carry no API key." "Rate-limit the password-reset endpoint harder than everything else." The managed rules protect you from generic attacks; custom rules protect the specific shape of your application, which is usually where the real incidents come from.
Rate limiting, and how to tune it so it works
Rate limiting is the control people enable and then quietly break, because they set it by guessing. The mechanism you are configuring is: a counting key, a threshold over a window, and a mitigation action for a duration.
The counting key is the single most important choice. Keying purely on client IP is the naive default and it is wrong for two opposite reasons: a corporate NAT or mobile carrier puts thousands of legitimate users behind one IP (you throttle real traffic), while a competent attacker rotates across a botnet's worth of IPs (you catch none of them). Better keys combine signals — IP plus a request characteristic, a session cookie, or a fingerprint — so you count actors, not addresses.
Tune the threshold from data, not intuition. Pull your real traffic and look at the request rate a genuine heavy user generates at p99 against the endpoint you're protecting. Set the limit meaningfully above that and below what an abusive client produces. If you can't see daylight between the two, the endpoint itself may be too expensive and the fix is caching or a captcha, not a rate cap. Set the mitigation duration long enough to actually deter (a one-second block does nothing) but short enough that a falsely-flagged user isn't locked out for an afternoon. And log in count-only mode first: watch what would have been blocked for a few days before you switch the action to block.
Bots and Turnstile
Bot management scores every request on the likelihood it came from automation, using behavioral signals, network reputation, TLS/HTTP fingerprints, and machine-learning models trained across Cloudflare's traffic. You then act on the score — allow the good bots you want (search crawlers, uptime checks), challenge or block the rest.
Turnstile is the piece worth understanding in detail, because it replaces reCAPTCHA without reCAPTCHA's two worst properties: grinding image puzzles and Google's cross-site tracking. Turnstile runs a set of non-interactive challenges in an embedded frame — lightweight proof-of-work and browser-integrity probes, behavioral checks, and reputation lookups — and for the overwhelming majority of real users it resolves with no click at all. It does this without setting third-party tracking cookies; the result is a signed token your backend verifies server-side against Cloudflare's siteverify endpoint. You put the widget on the form, you validate the token on submit, and you keep the friction on the bots instead of your customers. It works whether or not the hostname is proxied through Cloudflare, so you can adopt it standalone.
Hiding the origin IP — and why a leak defeats everything
Here is the failure mode I flagged earlier. All of the above — WAF, rate limits, bot scoring — happens at Cloudflare's proxy. If an attacker learns your origin's real IP, they connect straight to it and every one of those controls is bypassed. The proxy is guarding the front door while the back door has the same lock it always did.
Origin IPs leak in mundane ways: historical DNS records that predate Cloudflare and live forever in passive-DNS databases, an Received header in outbound email from the same host, an SSRF bug that echoes the machine's own address, a subdomain (origin., direct., staging.) that was never proxied, or a TLS certificate transparency log. Treating the origin IP as a secret is necessary but not sufficient, because you cannot reliably keep it secret.
The durable fix is to make the origin refuse anyone but Cloudflare. Two layers, together:
- Network layer — configure the origin's security group or firewall to accept traffic only from Cloudflare's published IP ranges. A direct connection from a random host is dropped at the packet level.
- Cryptographic layer — enable Authenticated Origin Pulls, which is mTLS from Cloudflare to your origin. Cloudflare presents a client certificate on the connection to your origin; your origin is configured to require and verify it. Now even a source inside Cloudflare's IP ranges, or a spoofed one, can't complete the handshake without the certificate. The IP filter stops the noise; the mTLS proves it's really your proxy.
Skip this and the reverse proxy is theater. Do it and the only path to your origin is through the controls.
Zero Trust and Access, instead of a VPN
The last shift is for internal apps — the admin panels, dashboards, and staging sites that traditionally hid behind a VPN. Cloudflare Access turns the same proxy into an identity-aware gateway. Instead of "you're on the network, therefore you're trusted," each request to a protected app must carry a valid identity, checked against a policy: this Okta/Google group, from these countries, with a device posture signal, gets in; everyone else is challenged or denied. The proxy issues and validates a signed JWT per session, so authorization is evaluated at the edge on every request rather than once at VPN login.
Paired with cloudflared tunnels, the origin makes an outbound-only connection to Cloudflare and has no inbound ports open at all — there is no VPN concentrator to attack and nothing listening on the public internet to find. For a team drowning in VPN client support tickets, this is often the most tangible security-and-sanity upgrade on the list.
The cost angle
Most of the primitives — proxying, TLS, basic WAF, and Turnstile — sit at the free or low tiers, which is why the barrier to a real security improvement here is configuration effort, not budget. The paid ceilings are the advanced bot management ML, granular rate-limiting rules, and higher Access seat counts. The framing that keeps the spend honest: you are consolidating DDoS absorption, WAF, bot defense, and remote access into one proxy, which usually retires a separate WAF appliance, a captcha vendor, and a chunk of VPN infrastructure. Price the replacement against what you decommission, not against zero.