Cloudflare makes internal Workers private by default, conceding developer discipline never held

Cloudflare has shipped the ability to apply Cloudflare Access to an individual Worker or to every Worker in an account, so deployments sit behind a company login by default ^[1]. The interesting part is the reasoning the company puts in writing: the goal is to stop "relying on each developer to set that up themselves" ^[1].

That is a retirement notice for the previous control. Access used to be configured at the hostname level, which meant a policy on every domain a Worker was reachable on ^[7]. Add a new custom domain and you had to update the policy first, or that hostname served unauthenticated traffic ^[8]. The protection was not a property of the application; it was a property of a list someone had to maintain, and lists like that decay in the direction of exposure.

Now the policy binds to the Worker, and Cloudflare enforces authentication before any request reaches application code, whether it arrives via a custom domain, a route, a workers.dev subdomain, or a preview URL ^[6][9]. You pick the blast radius: previews only, or all hostnames ^[9]. Preview-only covers every preview URL generated on each new deployment ^[10]; all hostnames covers custom domains, routes, workers.dev subdomains and previews together ^[11]. At the account level, one policy makes every Worker, current and future, private from the moment it is created, scoped to preview traffic, production traffic, or both ^[13]. According to Cloudflare, preview-only is the setting for shops whose production Workers are deliberately public but who never want an in-progress deployment reachable ^[14].

Two details decide whether this is a control or a preference. First, an individual Worker can bypass the account-wide policy when it needs to be public ^[15]. Second, when several policies overlap, the most specific wins: hostname, then Worker, then account ^[16]. Read those together and the account-level default is the weakest of the three layers, overridable by anything more specific ^[19], which makes it a default rather than a guarantee ^[20]. The audit question shifts from "did the developer remember" to "who is holding the bypasses, and why". The announcement describes the bypass but does not describe an approval or logging workflow around it ^[21].

The identity plumbing is the quiet win. With Access enabled, the authenticated user's email, name and groups arrive in the Worker's context via ctx.access.getIdentity(), with no JWT validation to write ^[4][17]. Hand-rolled token verification is a reliable source of subtle authorisation bugs, and this removes the reason to write it. Authentication itself can run through an existing identity provider, or be restricted to specific addresses, email domains or groups, with service tokens for agents ^[12]. Cloudflare has also open-sourced an example internal static site platform in which every deployed Worker is private ^[5].

The framing in the post is that AI has let employees on every team build applications quickly, and that any of them can deploy to the public Internet and accidentally expose internal work or company data ^[18]. That is a fair description of the failure, and the fix is honest about its own scope: it changes the default, not the review.

Worth watching: whether organisations set the account policy to cover production or only previews ^[13], since preview-only leaves the public surface untouched; and whether the bypass list ^[15] grows into the same unmaintained inventory the hostname-level policies were ^[7][8]. A default that everyone exempts is a report, not a control.