Cloudflare Is Making Internal Workers Private by Default

Cloudflare has introduced a simple solution to a problem that is getting worse as more people rapidly build and deploy internal applications.

Instead of expecting every developer to remember to configure authentication correctly, Cloudflare Access can now be attached directly to a Worker or applied across every Worker in an account. Authentication happens before the request ever reaches the application code.

That distinction matters.

Previously, Access protection was primarily configured around hostnames. Add another domain or deployment path without updating the policy and you could accidentally expose the application. Now the security policy follows the Worker across custom domains, routes, workers.dev addresses and preview deployments.

Administrators can also make every current and future Worker private automatically, while explicitly exempting applications that are supposed to be public.

This is the right way to approach the security problems created by rapidly built internal tools.

The solution is not another warning telling developers to remember authentication.

Make the safe configuration the default.

Cloudflare also exposes the authenticated user's identity directly through the Worker's context, including email, name and groups. That removes another piece of authentication plumbing developers previously had to implement themselves.

The timing is particularly relevant with AI-assisted development. It is becoming incredibly easy for someone inside a company to describe a tool, generate it and deploy it before anyone has thought carefully about whether the rest of the Internet should be able to reach it.

Cloudflare's answer is refreshingly boring security engineering:

Build quickly if you want.

But start private, and make somebody deliberately choose public.

That is a much better failure mode.

Read Cloudflare's announcement.

Read the Cloudflare Access documentation.