Protect / Cloudflare Security
WAF rules, rate limits, DNS posture and origin lockdown, tuned so the rules do not break the paths your business depends on.
TechSteps configures Cloudflare as a security layer rather than a proxy that happens to be switched on: WAF rules tuned to your application, rate limiting derived from real traffic, DNS posture, and an origin locked so it only accepts Cloudflare traffic. The rules are tested against login, API, admin and checkout paths so protection does not break the business.
What this solves
Cloudflare in front of a site with default settings does something useful and much less than people assume. The proxy is enabled, the orange cloud is on, and the origin is still directly reachable while the rules are generic.
The opposite problem is equally common. Security settings are turned up, and suddenly the WordPress admin will not load, the REST API returns challenges, a payment webhook stops arriving, or checkout intermittently fails for customers on mobile networks. The rules are then switched off entirely.
Getting this right means understanding which paths in your application are sensitive, which are expensive, which receive machine traffic that must never be challenged, and configuring accordingly.
When people call us
If more than one of these sounds familiar, the underlying cause is often a single issue rather than several separate ones.
Technical scope
Not every engagement includes all of this. The scope is agreed in writing before we start, and anything excluded is named rather than left ambiguous.
How we approach it
Existing rules, page rules, DNS records and cache settings. Most accounts have accumulated rules nobody can explain, some of which contradict each other.
Login, admin, REST and AJAX endpoints, webhook receivers, checkout. These are where security rules cause damage, so they are identified before any rule is written.
Firewall restricted to Cloudflare ranges, and any DNS record that exposes the origin address addressed. Without this, the entire configuration can be bypassed.
Rate limits and bot rules derived from your actual logs rather than from a template, then deployed in log-only mode first where the platform supports it.
After each change: admin login, a REST request, a webhook delivery, a test checkout. This is the step that gets skipped and is the reason rules get disabled later.
What it does, why it exists, and what would break if it were removed. Undocumented rules eventually get deleted by someone troubleshooting an unrelated problem.
What goes wrong
These are the patterns we see most often when we are called in to fix someone else's work, or our own from earlier in our careers.
Cloudflare is bypassed by connecting to the origin IP. Every rule configured at the edge becomes optional from the attacker's point of view.
Challenges applied to everything, including API clients and webhook senders that cannot solve them. Integrations fail silently and the cause is not obvious.
Cart, account or admin responses cached at the edge. Customers see stale or, occasionally, someone else's content. This is the most damaging Cloudflare misconfiguration.
A payment provider callback is classified as bot traffic and challenged. Orders stay unpaid or unconfirmed, and nothing errors visibly on your side.
Dozens of rules created over years by different people. Nobody knows which are load-bearing, so nobody touches any of them.
Questions we actually get asked
For many small sites, yes, particularly once the origin is locked down and basic rules are in place. Rate limiting, richer WAF rules and bot management are stronger on paid tiers. We would rather configure the free plan well than sell you an upgrade you do not need, and we will tell you plainly where a limitation is the plan.
Almost always a rule challenging or blocking admin-ajax, the REST API, or the login path. WordPress uses these for ordinary functionality, so a generic rule aimed at attack traffic catches normal operation. The fix is path-specific rules rather than a global security level.
Configure the origin firewall to accept web traffic only from Cloudflare IP ranges, and remove the DNS records that leak the origin address. Also check for unproxied subdomains, since a mail or staging host pointing at the same server exposes it. This is the single most important step and it is frequently missing.
It can, and the symptom is confusing inconsistency where a change appears for some visitors and not others. The two layers need to agree about what is cacheable and for how long, and both must exclude the same personalized paths. We configure them as one system rather than two.
Yes. Rules can be deployed in a log-only mode first so you can see what would have been blocked before anything is enforced. The origin firewall change needs care and is verified before the previous access path is removed.
Describe the system and what is going wrong with it. A short technical conversation is usually enough for us to tell you whether this is the right work and roughly what it involves.