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

Turning on Cloudflare WAF managed rules and layering your own custom rule to block a specific path is one of the fastest ways to harden an application without changing origin infrastructure. You route traffic through Cloudflare’s connectivity cloud, let the managed WAF rulesets catch the broad, known attacks, then use a precise custom rule to enforce your own path-level policy.

Below is a step‑by‑step walkthrough, written from the perspective of someone who’s actually had to migrate legacy ACLs and firewall rules into a Zero Trust, edge‑enforced model.

Quick Answer: Enable Cloudflare WAF managed rules in your zone’s Security → WAF settings, then create a custom WAF rule that targets the exact path you want to block (for example, using http.request.uri.path contains "/admin" with an action of Block). The managed rules handle broad attack coverage; the custom rule enforces your specific path policy.

The Quick Overview

What It Is: Cloudflare WAF (Web Application Firewall) is an edge‑based security layer that inspects HTTP(S) traffic for attacks and applies both managed and custom rules before requests ever hit your origin.
Who It Is For: Security, DevOps, and platform teams that need to protect websites, APIs, and AI-enabled apps from common exploits while enforcing path‑specific policies without editing web server configs or writing new code.
Core Problem Solved: It eliminates blind spots and brittle perimeter rules by evaluating every request at Cloudflare’s edge, letting you apply consistent, auditable policies (like blocking sensitive paths) across all traffic.

How It Works

When a user or bot sends a request to your site or API:

Traffic Routes Through Cloudflare’s Edge: DNS or a proxy configuration sends traffic through Cloudflare’s global network, within ~50 ms of almost all Internet users.
WAF Managed Rules Run First: Cloudflare’s managed rulesets (like the OWASP Core Ruleset and Cloudflare Managed Rules) inspect the request for known attack signatures—SQLi, XSS, RCE, path traversal, and more.
Custom Rules Apply Your Business Logic: Your own WAF rules match on properties like path, query string, headers, IP, ASN, or country. For your use case, a rule targeting a specific http.request.uri.path will block that URL pattern outright.
Allowed Traffic Continues to Origin: If the request passes all rules, Cloudflare forwards it to your origin (or Workers / other edge services); blocked or challenged traffic never reaches your infrastructure.

From an architecture standpoint: the edge is your enforcement point. If you can’t say “this request was evaluated here, against these rules, with this log,” you don’t have a defensible posture. Turning on managed rules and adding a path‑specific rule gives you that clarity.

Step 1: Turn On Cloudflare WAF Managed Rules

The exact UI can evolve, but the flow is consistent. You’ll be working in the Cloudflare dashboard on your chosen zone (domain).

Log in and select your site
- Go to https://dash.cloudflare.com.
- Choose the account and the domain you want to protect.
Navigate to WAF
- In the left‑hand navigation, select Security.
- Under Security, click WAF.
Locate Managed Rules
- On the WAF page, find the Managed rules tab or section.
- This is where Cloudflare’s curated rulesets live (e.g., Cloudflare Managed Rules, OWASP Core Ruleset).
Enable core managed rulesets
- Turn on:
  - Cloudflare Managed Rules – Cloudflare’s continuously updated, attack‑focused protection.
  - OWASP Core Ruleset (CRS) – Broad coverage for OWASP Top 10 style vulnerabilities.
- For each ruleset, set it to an appropriate Mode:
  - Block for production environments you’re confident in.
  - Simulate/Log (if available) when you want to monitor impact before enforcing.
Select a ruleset “sensitivity” or “paranoia” level (if presented)
- Start with Medium if you’re new to WAF, then:
  - Monitor WAF logs in Security → Events.
  - Increase to High once you’re comfortable with false positive rates.
Save / apply changes
- Confirm or publish changes so the rulesets are active globally.

Operational tip: Treat this like turning on a security “bouncer” for common attacks. Managed rules should be on for every Internet‑facing app unless you’ve validated another equivalent control in front of Cloudflare (which is rare).

Step 2: Plan Your Custom Path‑Blocking Rule

Before you click anything, decide:

The exact path or pattern you want to block
Examples:
- /admin
- /admin/ and everything beneath it (/admin/*)
- /tmp/debug.php
- /internal/healthcheck?token=123 (you’d typically protect this differently, but you may temporarily block)
How strict you want the match to be:
- Match exact path only
- Match path that contains a segment
- Match multiple paths via an expression (e.g., /admin OR /config)

For most cases where you want to stop anyone from reaching a sensitive area from the public Internet, a match on http.request.uri.path is sufficient.

Common patterns:

Block everything under /admin:

http.request.uri.path starts_with "/admin"

Block one specific endpoint:
```
http.request.uri.path eq "/debug.php"
```

Step 3: Create a Custom WAF Rule to Block the Path

Go back to WAF in the dashboard
- Security → WAF.
- Switch to the Custom rules (or “Firewall rules”) tab.
Add a new rule
- Click Create rule or Add rule.
- Give it a clear name, e.g.:
  - Block public access to /admin
  - Block debug endpoint /debug.php
Build the rule expression

You’ll use Cloudflare’s Expression Builder or Advanced mode to target the path:

Example: Block all access to /admin and anything under it

Using the builder:
- Field: URI Path
- Operator: starts with
- Value: /admin
Expression (advanced):
```
http.request.uri.path starts_with "/admin"
```
Example: Block exactly /debug.php
- Field: URI Path
- Operator: equals
- Value: /debug.php
Expression:
```
http.request.uri.path eq "/debug.php"
```
You can also combine conditions if needed—e.g., block only for unauthenticated users, or only from certain countries—but for a simple hard block, a single path condition is enough.
Set the action to Block
- Action: Block (not “Allow,” “Bypass,” or “Log”).
- This ensures any request matching the path is stopped at the edge and never reaches the origin.
Set rule priority (ordering)
- Rules are evaluated in order; higher‑priority (lower number) rules run first.
- For a sensitive path block, place it fairly high in the rule stack so it isn’t accidentally bypassed by broader allow rules.
Deploy the rule
- Save or deploy the rule.
- Propagation is typically near‑instant across Cloudflare’s global network.

Step 4: Test and Validate the Rule

Treat this like validating a firewall change:

Use a browser or curl from an external network
- From a normal client (not your origin’s local network), request the blocked path:
  - https://yourdomain.com/admin
  - https://yourdomain.com/debug.php
Confirm the response
- You should receive a 403 or a Cloudflare “blocked” page, depending on how your account is configured.
- The origin should not see this request in its logs.
Check Cloudflare Security Events
- In the dashboard, go to Security → Events (or Security → WAF logs).
- Filter by:
  - Action: Block
  - Service: WAF
  - Rule name: Your custom rule name
- Confirm your test request shows up as blocked with the rule you created.
Monitor for unintended blocks
- For the first few days, keep an eye on WAF events:
  - Make sure you’re not blocking legitimate internal tooling that now relies on this path from outside (and should be migrated to Zero Trust access).
  - If you see false positives, refine the rule with additional conditions (e.g., block only for certain user agents or unauthenticated patterns).

Features & Benefits Breakdown

Core Feature	What It Does	Primary Benefit
Managed WAF Rulesets	Applies Cloudflare’s curated, continuously updated rules (e.g., OWASP CRS).	Broad protection against known attacks without manual rule authoring.
Custom WAF Rules (path-based)	Lets you define conditions (like specific URI paths) and actions.	Enforces your own security policies, such as blocking sensitive paths.
Edge-Level Enforcement & Logging	Evaluates requests globally at the edge and logs decisions centrally.	Reduces origin risk and simplifies auditing, change control, and forensics.

Ideal Use Cases

Best for blocking legacy admin interfaces: Because it lets you immediately cut off Internet access to /admin, /phpmyadmin, or legacy consoles while you migrate them to Zero Trust or internal-only access.
Best for disabling risky debug or test endpoints: Because it lets you quickly block /debug.php, /test/login, or other temporary paths that must never be reachable in production.

Limitations & Considerations

Not a substitute for identity-based access: Blocking a path is a blunt instrument. For admin UIs and internal apps, pair WAF rules with Cloudflare Access (Zero Trust) so every request is evaluated for identity and context, not just path.
Be careful with broad path patterns: A rule like contains "/admin" could unintentionally block legitimate paths (e.g., /static/admin-logo.png). Prefer starts_with "/admin" or exact matches and test before enforcing in critical environments.

Pricing & Plans

Cloudflare offers multiple plans that include WAF capabilities:

Pro/Business Plans: Best for smaller teams or single‑app owners needing managed WAF, basic custom rules, and protection for a few domains without deep SASE or network modernization.
Enterprise Plan: Best for larger organizations needing advanced WAF controls, granular rule tuning, prioritized support, log streaming, and tight integration with Cloudflare One, Network Services, and the broader connectivity cloud.

For detailed pricing and to map WAF capabilities to your scale and compliance requirements, contact Cloudflare sales.

Frequently Asked Questions

Do I need to change anything on my origin server to use WAF managed rules and path blocking?

Short Answer: No, not typically—WAF runs at Cloudflare’s edge, in front of your origin.

Details: Once your DNS or proxy configuration routes traffic through Cloudflare, all WAF inspection and blocking happen in the connectivity cloud. You don’t need to update web server configs (like mod_security rules) to use managed or custom WAF rules. That’s the core benefit: you centralize rule management at the edge instead of scattering ACLs and rewrite rules across multiple origin stacks.

Can I block a path only for certain IPs, countries, or user agents?

Short Answer: Yes. You can combine path conditions with IP, ASN, country, headers, and more in a single custom rule.

Details: Custom WAF rules use Cloudflare’s expression language, which supports multiple fields and Boolean logic. For example, you could block /admin only from outside your corporate IP ranges:

http.request.uri.path starts_with "/admin"
and not ip.src in {203.0.113.0/24 198.51.100.0/24}

Or block a path for specific user agents or countries. This lets you move complex perimeter ACL logic into a single, centralized policy evaluated at Cloudflare’s edge.

Summary

Turning on Cloudflare WAF managed rules gives you broad, always‑on protection against common web attacks, enforced at the edge across Cloudflare’s global network. Adding a custom WAF rule to block a specific path lets you quickly harden fragile areas—admin consoles, debug endpoints, legacy tools—without touching origin code or firewall hardware.

From an architectural perspective, you’re moving from scattered, device‑specific ACLs to a unified, edge‑based control plane where every request is evaluated and logged. That’s foundational for a defensible, Zero Trust‑aligned posture—especially as you start protecting APIs and AI‑enabled apps.

Next Step

Get Started