Does a Cloudflare Access Bypass rule expose my origin to everyone, or only matching traffic?

Question

I'm setting up Cloudflare Zero Trust in front of an internal admin tool served through a cloudflared tunnel, and I want most paths to require SSO login while a health‑check endpoint stays reachable without authentication. The Access policy types include Allow, Require, Block, and Bypass, and the documentation describes Bypass as letting matching traffic skip the identity check entirely.
My concern is scope. If I add a Bypass policy for a specific path or IP range on an application, does the rest of the application still fall through to my Allow/Require rules, or does the presence of a Bypass rule change how the default decision is evaluated for non‑matching requests? I'm also unsure whether evaluation order matters when multiple policies are attached to one application, and what happens to requests that match no policy at all.
Assuming a current Zero Trust dashboard configuration with an IdP already enrolled:

Is policy evaluation first‑match‑wins, and does Bypass short‑circuit the remaining rules?
What is the default decision for a request matching no policy on a protected application?
Is there a supported way to confirm, before rollout, that only the intended path is publicly reachable?

Tasadduq Burney · Answer

Short answer
A Bypass policy only applies to requests that match its conditions (path, IP, header, etc.). All other traffic is evaluated against the remaining policies for that application. The presence of a Bypass rule does not automatically expose the entire origin.
How Cloudflare Access evaluates policies

Policies are evaluated in the order they appear in the dashboard – first‑match‑wins.
When a request matches a Bypass rule, Cloudflare skips the identity check and forwards the request directly to the origin. No further policies are considered.
If no policy matches, the request is denied (blocked) by default.

Implications for your health‑check endpoint
Place the Bypass rule *after* any global Allow or Require rules that should protect the rest of the application. That way, the Bypass only short‑circuits identity checks for the health‑check path, while all other paths still hit the Require rule and are gated by SSO.
Typical policy order
1. Require  – applies to all paths (e.g., /admin/*)
2. Bypass   – applies to /health or your chosen path
3. Block    – optional catch‑all for anything else

Default decision for unmatched requests
If a request does not match any policy, Cloudflare Access will block the request – it will not be forwarded to the origin.
How to verify the intended behavior before rollout

Check policy order – In the Cloudflare dashboard, open the Access application, click Policies, and confirm that the Bypass rule is positioned after the Require rule that protects your admin paths.
Test the health‑check endpoint – Run:
curl -I https://your‑domain.com/health

The response should be 200 OK without any authentication headers.
Test a protected path – Run:
curl -I https://your‑domain.com/admin

You should see a 302 Found redirect to your IdP or a 403 Forbidden if you’re not authenticated.
Review Access logs – In the Cloudflare Analytics or Access logs, check that the health‑check request is marked as Bypass and the protected request is marked as Require (or Block).

One diagnostic detail that could change the recommendation
Do you have any other policy that applies to all paths (e.g., a global Allow rule) that might override the Bypass? If such a rule exists, it could unintentionally expose the entire application.
Summary
A Bypass rule is a fine‑grained exception: it does not open your origin to everyone, only to the traffic that matches its conditions. Keep the policy order intentional, verify with curl and logs, and double‑check for any global Allow rules that could interfere.

Does a Cloudflare Access Bypass rule expose my origin to everyone, or only matching traffic?

1 answer

Short answer

How Cloudflare Access evaluates policies

Implications for your health‑check endpoint

Typical policy order

Default decision for unmatched requests

How to verify the intended behavior before rollout

One diagnostic detail that could change the recommendation

Summary

Your perspective belongs here.

0 question comments