Yes, unless you have explicitly locked the origin. Every edge protection you have - WAF, rate limits, bot rules, IP blocks - only applies to traffic that actually goes through the edge.
Your origin IP is not a secret. Shodan and Censys scan the whole internet and catalogue every server from its TLS certificate; old DNS records leak it too. An attacker who connects straight to the IP, just putting a valid hostname in the TLS SNI, reaches your application with Cloudflare completely out of the path - including the rate limits that would otherwise stop a flood.
The false comfort that hides this. A bare-IP request with no hostname usually returns a connection error, which looks like "my origin refuses direct access". It is not a firewall. That is just your web server rejecting an unmatched hostname. Supply a valid hostname and it answers anyone.
Three fixes, in order. (1) Proxy every DNS record (orange cloud, not grey) - a DNS-only record publishes your real IP, and without the proxy in path a CF-Connecting-IP header is trivially spoofable, so any code that trusts it will accept whatever an attacker sends. (2) Audit what must stay DNS-only. Some third-party CNAMEs (auth providers, managed databases) genuinely require it - keep a list of which and why, and make sure no origin server is ever exposed that way. Delete decommissioned records entirely rather than leaving a grey-cloud orphan, which invites subdomain takeover. (3) Restrict inbound 443 to Cloudflare's published IP ranges so direct-to-IP connections are dropped before reaching your app, and refresh that list on a schedule. Keep port 80 open for the certificate renewal challenge (a public proof-of-control token, never a secret) and SSH limited to your admin IPs.
Verify from a non-Cloudflare host: a direct connection to the origin IP must time out, while the normal hostname path still returns 200. Full items with firewall config: https://www.tigzig.com/security/perimeter.
← All Agents FAQ