Cloudflare Tunnel is not a trust boundary

Reachability is not permission

Home servers often need a way to reach one useful service without turning the whole network into a remote control panel. Cloudflare Tunnel is one way to solve the transport problem. Cloudflare describes `cloudflared` as creating outbound-only connections from an origin to Cloudflare's network, so the origin does not need a publicly routable IP. Its documentation also describes allowing only those outbound connections at the firewall, rather than accepting arbitrary inbound traffic.

That is a valuable boundary, but it answers a narrow question: **how can traffic get from Cloudflare to this service?** It does not answer who should be allowed to use the service, what they may do after they arrive, or whether the application itself has safe roles.

Treat those as three separate decisions:

The first is transport configuration. The second can be expressed with an Access policy. The third still belongs to the application. Calling all three “the tunnel” makes review harder because a green connection test can hide a missing authorization decision.

• **Route:** which hostname or path maps to which service?
• **Identity:** which people, devices or service clients may reach it?
• **Application permission:** once inside, may they read, change, administer or export anything?

The public-hostname trap

The phrase “no public IP” is easy to hear as “not public”. Those are different properties. Cloudflare's route documentation says a published application route exposes an application to the Internet through a domain. It also says that anyone on the Internet can access the application at the specified hostname until you create an Access application to allow or block specific users.

So a route can hide the origin while making the front door public. That may be exactly what you want for a public website. It is a poor default for a household dashboard, an administrator, a camera interface or anything that contains private information.

Cloudflare Access is the separate identity gate. Its policy documentation describes actions such as Allow, Block, Bypass and Service Auth, combined with selectors and values. It also calls out broad rules such as including everyone or all valid email login methods as misconfigurations that can make an application available to anyone who satisfies that broad condition.

The practical lesson is not “never publish a hostname”. It is “write down whether the hostname is public, private-to-identities or intentionally anonymous before you create the route”.

A worked example: one private dashboard

Imagine a small household energy dashboard. The goal is for two explicitly chosen household identities to view it remotely. It is not a public demo, and nobody needs to administer the underlying host from the browser.

Before making the route live, write a short access card:

The card is deliberately boring. Boring is useful here: a reviewer can compare the intended audience with the actual Access selectors and the application roles without reconstructing the design from a pile of settings.

• **Route:** one named hostname to the dashboard service only. Do not use a broad network route when one service is enough.
• **Identity:** an Access application with an allow rule for the chosen identities, plus any required device or authentication condition. Avoid a catch-all include rule.
• **Application:** the dashboard account is read-only for ordinary users. Administration stays on a separate path with a separate control.
• **Evidence:** record the route, policy revision, test date and results. Do not paste tokens, private addresses or configuration exports into the record.
• **Recovery:** define who can disable the route or policy, and how to restore the last known-good configuration if a change locks everyone out.

Test the boundary from the outside

Do not stop after confirming that the dashboard loads for its owner. Test the decisions that are supposed to fail as well as the one that is supposed to work:

Record pass or fail, the observed response, and the configuration revision. Keep the record small enough to repeat after every route or policy change. A useful result might say “wrong identity rejected at the Access gate” rather than “security checked”. The former can be tested again.

• From an outside network, the chosen identity reaches the expected read-only view.
• An unauthenticated private window is rejected or sent to the intended sign-in flow.
• A different identity is rejected, not merely shown a blank page.
• The dashboard's own admin action is unavailable to the read-only account.
• If the connector is stopped, the hostname fails closed or shows a controlled error; it does not reveal a second unreviewed path.
• After a policy edit, repeat the wrong-identity test. A remembered browser session is not independent evidence.

What the tunnel does not solve

Tunnel reachability does not patch the dashboard, create strong application accounts, remove sensitive data, or make a compromised Cloudflare account harmless. It does not make an admin interface safe for every authenticated user. It does not prove that the origin service is listening only where you intended, or that a second port, hostname or vendor integration has not created another path.

The tunnel is also not a reason to skip updates and backups. If a route or policy change causes an outage, you need a known configuration version, an owner and a reversible recovery action. If the application is wrong, the tunnel may deliver that wrongness very efficiently.

These are limits, not objections. The value of the tunnel is narrower and clearer: it can provide a controlled connection path without requiring the origin to accept general inbound traffic. Identity and application authorization still need their own evidence.

Keep a four-line preflight

Before exposing a home service, answer four questions in plain language:

If those answers fit on a small card, the setup is easier to review and recover. If they do not, adding another tunnel setting will not make the boundary clearer.

Cloudflare's product behaviour and policy screens can change, so re-check the current documentation and your own account configuration when you revisit the route. This article is a decision pattern, not a claim that one vendor configuration guarantees safety. What we would do next is remove one unnecessary public hostname, replace it with the narrowest route and identity policy that meets the real need, and run the failure tests before calling the work finished.

• What exact hostname, path and service are reachable?
• Which identities or clients are allowed, and what broad rule would accidentally include more?
• What can an authenticated user do inside the application?
• What test proves the allowed path works and the nearest forbidden paths fail?

Sources and limits

This article synthesises the sources below into a practical explanation. It is not a security standard, legal advice, or a guarantee that guidance current at review time still applies — check the review date above against your own situation.

1. Cloudflare Tunnel — Cloudflare. Explains that cloudflared creates outbound-only connections to Cloudflare and that a tunnel can connect resources without a publicly routable origin IP.
2. Add routes — Cloudflare. Explains that a published application route exposes an application at a hostname and states that anyone on the Internet can access it until an Access application is used to allow or block specific users.
3. Access policies — Cloudflare. Explains that Access determines who can reach an application through policy actions, selectors and values, and documents broad include rules as a common misconfiguration.

More from Server Attic

• 2026-09-04

  A web page is not permission for your AI agent

  An agent can use a page, document or message as evidence without treating instructions inside it as authority. Design that boundary before connecting powerful tools.

• 2026-08-28

  Automate disk cleanup only after you can explain the growth

  A full disk invites a hurried deletion. A safer home-server workflow identifies the owner, growth rate, reclaimable data, retention need and recovery path before cleanup becomes automatic.

• 2026-08-26

  Local AI stays private only if the whole workflow does

  Running a model on your own machine can remove one remote data path, but prompts, tools, logs, saved outputs, backups and sharing still decide where information travels.