How do I turn on Cloudflare WAF managed rules and create a custom rule to block a specific path?

Many teams turn on Cloudflare’s WAF and immediately reduce risk from common attacks, but you only get full value when you both enable managed rules and add a few precise custom rules for your own URLs and patterns. One high-impact example: blocking or challenging requests to a specific path that should never be hit by the public Internet.

This guide walks through, step‑by‑step, how to:

Turn on Cloudflare WAF managed rules
Create a custom WAF rule to block a specific path
Test, tune, and safely deploy those controls in production

Quick Answer: Enable Cloudflare’s WAF managed ruleset from the WAF tab in the dashboard, set it to “Block” for your zone, then create a custom rule that matches http.request.uri.path (for example /admin or /internal/health) and set the action to “Block.” Always test in “Log” or “Skip” mode first if you’re unsure.

The Quick Overview

What It Is: Cloudflare WAF managed rules are prebuilt, continuously updated security rules that detect and block common attacks (SQL injection, XSS, RCE, etc.), while custom WAF rules let you enforce your own policies based on path, headers, IP, country, and more.
Who It Is For: Security, DevSecOps, and platform/infra teams responsible for protecting websites, apps, and APIs that sit behind Cloudflare’s connectivity cloud.
Core Problem Solved: You need to stop real-world attacks quickly, without writing every signature yourself, and you also need tight, app‑specific controls—like blocking a sensitive or deprecated path—that generic rules can’t know about.

How It Works

At a high level, Cloudflare’s WAF sits in front of your origin on Cloudflare’s global edge network. Every HTTP(S) request to your website, app, or API is:

Routed through the Cloudflare edge instead of hitting your origin directly.
Evaluated against managed rules (Cloudflare‑maintained protections for known attack patterns).
Evaluated against your own custom rules (for your URLs, parameters, IPs, etc.).
Allowed, blocked, challenged, or logged based on those rule decisions.

Because this all happens at the edge, attacks are absorbed close to the user—your origin never sees blocked traffic, and you get consistent security enforcement in every region.

1. Confirm your site is proxied through Cloudflare

Before any WAF rule does anything, your DNS records must be proxied (orange‑cloud) so traffic flows through Cloudflare:

Log in to the Cloudflare dashboard.
Select your domain (zone).
Go to DNS.
Ensure your relevant A/AAAA/CNAME records show the orange cloud icon (proxied).
- If they’re gray, click to toggle them to orange.
- Changes propagate quickly but can take a few minutes depending on DNS cache.

Only traffic that passes through Cloudflare’s edge will be evaluated by the WAF.

2. Enable Cloudflare WAF managed rules

Cloudflare’s managed rules give you broad, automatic protection with minimal configuration.

In the dashboard, select your domain.
Navigate to Security → WAF.
Go to the Managed rules tab.
Locate the Cloudflare Managed Ruleset (name may vary slightly depending on product tier, e.g. “Cloudflare Managed Ruleset,” “Cloudflare OWASP Core Ruleset,” etc.).
Toggle the ruleset On for your zone.
Choose the Default action for detected threats:
- Block – Directly blocks malicious requests (most common in production once you’ve validated).
- Challenge – Presents a challenge (e.g., CAPTCHA) instead of outright blocking.
- Log/Simulate – Useful for initial tuning; logs matches without blocking.
Review optional subsets:
- SQL injection protection
- Cross‑site scripting (XSS)
- Command injection / RCE
- File inclusion, traversal, and other OWASP categories
  Enable the ones relevant to your app; keep an eye on logs for false positives.

3. Tune managed rules (optional but recommended)

Once managed rules are enabled:

Let them run in Block or Challenge mode for non‑critical endpoints, or in Log mode if you’re cautious.
Use Security → Events to review WAF matches:
- Filter by Action (e.g., Blocked) and Service = WAF.
- Check which rules are firing and against which URLs/parameters.
For noisy or clearly benign patterns, create rule overrides:
- In WAF → Managed rules, select the relevant managed ruleset.
- Add an override to change the action or disable a specific rule ID for a particular path or parameter.

This keeps your WAF effective without breaking valid traffic.

Create a Custom WAF Rule to Block a Specific Path

Once your baseline managed rules are active, you can add a precise rule to block a particular path—for example, /admin, /internal/health, or /old-api/private.

Step 1: Decide what exactly to block

Define your target path and scope:

Single path (exact): /admin or /internal/metrics
Path prefix: /internal/ to cover /internal/*
Case sensitivity: Cloudflare’s comparisons can be case-sensitive; standardize or use operators thoughtfully.
Scope: Entire Internet or specific countries/ASNs/IP ranges?

Example goals:

Block all public access to /internal/metrics.
Block /admin except from a specific IP or internal range (for this, a more nuanced rule or Cloudflare Access is better).
Block a deprecated endpoint /old-api/private that should never be hit.

Step 2: Open the custom rules editor

In the Cloudflare dashboard, select your domain.
Go to Security → WAF.
Click the Custom rules tab.
Click Create rule (or Create custom rule).

Step 3: Build the rule expression

Cloudflare’s WAF uses a powerful expression language. For a simple “block this path” rule:

Name the rule clearly, e.g., Block /internal/metrics path.
Under When incoming requests match… build your expression.

Common patterns

Exact path match:

http.request.uri.path == "/internal/metrics"

Block a path prefix (any URL starting with /internal/):
```
starts_with(http.request.uri.path, "/internal/")
```

Block multiple specific paths:

http.request.uri.path in {"/admin", "/admin/login", "/internal/metrics"}

Block path except from a specific IP (example):
```
http.request.uri.path == "/admin"
and ip.src ne 203.0.113.10
```
(This allows 203.0.113.10 but blocks everyone else.)

Set the Action to:
- Block – For a path that should never be accessible.
- Challenge – If you want to slow down attackers but still let some users through.
Set Deployments / Status to Enabled.
Click Save or Deploy.

Step 4: Test your rule safely

Before trusting the rule in production, validate it:

From a browser or curl, request the path you blocked:
- e.g. https://yourdomain.com/internal/metrics
Confirm you see a Cloudflare block page (or challenge, depending on your action).
Check Security → Events:
- Filter for Service = WAF.
- Confirm your custom rule appears, with the expected action and rule name.

If you see unexpected blocks:

Double‑check the expression—especially starts_with vs exact equals.
Narrow the scope (e.g., from /internal/ to /internal/metrics).
Temporarily change the action to Log to observe behavior without impact.

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Cloudflare WAF Managed Rules	Applies continuously updated protections against OWASP Top 10 and other common web attacks.	Rapid, broad coverage without writing signatures yourself.
Custom WAF Rules & Expression Language	Lets you define granular policies on paths, methods, IPs, headers, query args, and more.	Enforce business‑specific controls like blocking a specific path or segment of traffic.
Edge Enforcement & Logging	Evaluates and logs requests on Cloudflare’s global edge before traffic hits your origin server.	Reduces load and risk on origin infrastructure with centralized, auditable policy enforcement.

Ideal Use Cases

Best for teams securing critical admin or internal paths: Because you can explicitly block or challenge access to sensitive URLs like /admin, /internal/, or deprecated APIs without touching origin configs.
Best for organizations standardizing WAF across many apps: Because managed rules provide a baseline shield across all zones, and custom rules let you layer app‑specific policies on top, all managed from the Cloudflare dashboard.

Limitations & Considerations

Over‑broad rules can block legitimate traffic: A generic prefix like starts_with(http.request.uri.path, "/api") might catch too much. Start with narrower expressions, test in Log mode if needed, and review Security Events before tightening.
Path blocking isn’t identity‑aware by itself: WAF rules evaluate request properties, not user identity. If you need strong, identity‑driven access control (SSO, MFA, per‑user logging) for sensitive internal paths, combine WAF with Cloudflare Access in Cloudflare One for true Zero Trust controls.

Pricing & Plans

WAF availability and feature depth depend on your Cloudflare plan:

Pro/Business/Enterprise tiers provide progressively richer WAF capabilities (more managed rulesets, higher limits for custom rules, advanced tuning).
All plans benefit from Cloudflare’s global edge network, where WAF enforcement happens within ~50ms of most Internet users.

For complex environments (multiple zones, strict compliance, AI‑enabled apps and APIs), the Enterprise plan unlocks advanced customization, higher limits, SLA commitments, and support.

Standard / Self‑Service Plans: Best for small to mid‑size teams needing strong, managed WAF protections and a handful of custom rules per site.
Enterprise Plan: Best for large or regulated organizations needing higher rule volumes, fine‑grained control, logging integration (SIEM), and architectural guidance for WAF and Zero Trust.

Frequently Asked Questions

Do I have to disable my origin WAF or firewall to use Cloudflare WAF?

Short Answer: No. You can run Cloudflare WAF in front of your existing tools, and many teams do.

Details: Cloudflare’s WAF runs at the edge, before traffic reaches your origin. You can keep any on‑prem or cloud WAF/firewall in place as an additional layer. Over time, many organizations shift more logic into Cloudflare to simplify operations and reduce hardware dependence, but it’s not required upfront. Just avoid conflicting behaviors (e.g., both layers rewriting the same headers) and use Cloudflare’s logs to tune which layer blocks what.

How do I know if my managed and custom rules are working correctly?

Short Answer: Use the Security Events view and test specific URLs to confirm that expected requests are blocked or allowed.

Details: After enabling managed rules and creating custom rules, go to Security → Events in the dashboard. Filter by Service = WAF and inspect recent events:

Confirm that your custom rule name appears when hitting the specific path.
Verify that the action (Block / Challenge / Log) matches your intent.
Watch for unexpected blocks on legitimate traffic; if you see them, refine your expressions or adjust actions. For deeper analysis, integrate logs into your SIEM to correlate WAF actions with application behavior.

Summary

Turning on Cloudflare WAF managed rules provides an immediate shield against common web attacks, while custom rules give you the precision to protect specific paths and patterns unique to your apps. The mechanism is straightforward: route traffic through Cloudflare’s connectivity cloud, evaluate each request at the edge against managed and custom rules, and block or challenge malicious or unauthorized requests before they hit your origin. Done right, this reduces attack surface, offloads your infrastructure, and gives you a single, auditable control plane for web security.

Next Step

Get Started