The Key to Letting Specific URLs Bypass Cloudflare Access

But what if you need to let something in without logging in, like a webhook or uptime check?

At first glance, it seems like you should just write a policy that “allows” everyone on a specific path. But that doesn’t work the way you’d expect. Here’s what’s really going on — and how to do it right.

How Cloudflare Access Works

To understand the fix, it helps to know how Access is structured:

• An Application is a protected resource — typically a domain or subdomain (e.g. app.example.com). You can optionally scope it to a specific path like /webhooks/stripe.
• A Policy controls who can access that application and under what conditions. Policies include an Action (Allow, Block, Bypass, etc.) and a Rule (like “email ends with @example.com” or “Everyone”).
• Cloudflare matches requests to the most specific application first. If multiple apps overlap, the one with the tighter match (e.g. a specific path) wins.

The Lightbulb Moment: You Need Two Applications

When I tried exposing a specific URL (like /webhooks/stripe) under my main application, I assumed I could just write an Allow policy for that path. But that still required users (or systems) to pass identity checks — not ideal for automated services. Plus, Cloudflare does not allow us to assign a path directly to a policy.

The fix is to create a second application in Cloudflare Access for the specific path you want to expose. For example:

1. One app protects app.example.com/* with your normal authentication policy.
2. A second app protects app.example.com/webhooks/stripe with a Bypass policy that includes Everyone.

Since Cloudflare evaluates the most-specific application first, the webhook path will bypass Access entirely, while the rest of your app remains locked down.

It’s Simple Once You Know

So if you’re wondering why your “Allow” rule isn’t letting traffic through — that’s why. Allow still enforces identity checks. Bypass skips them. And you can only apply different actions to different paths by splitting them into separate applications.

Once I made that shift, everything worked as expected — and now my webhooks come through without authentication, while everything else is protected behind login.