Cloudflare announced the launch of Cloudflare Access for Workers, a set of tools that enables an Access policy to be connected directly to a Worker application or to all Workers applications within an account. With this connection, applications are placed behind company login by default, without relying on every developer to remember to configure access controls separately.
The move comes as employees, supported by artificial intelligence tools, are able to build and deploy applications more quickly. Cloudflare believes this speed can also lead to internal applications or private data being accidentally exposed on the public internet. It therefore designed the new tools to make protecting applications hosted on Workers part of the deployment process itself.
Protecting the Application Regardless of How It Is Accessed
When Access is enabled on a Worker, Cloudflare enforces authentication before any request reaches the application code. This applies whether the user reaches the application through a custom domain, a path, a workers.dev subdomain, or a preview URL.
Previously, Access was configured at the hostname level, which meant creating separate policies for each domain through which a user could reach a Worker. Adding a new custom domain required updating the policy first; otherwise, that domain could be accessed without authentication. Now, the policy is connected to the Worker itself, automatically protecting the domains and URLs associated with it.
The protection scope can be selected as needed:
- Protect preview URLs only, including workers.dev URLs or custom domains used for previews.
- Protect all hostnames associated with the application, including custom domains, paths, workers.dev domains, and preview URLs.
Account-Level Default Policy
Teams managing a large number of Workers applications can configure an Access policy once at the account level. All current and future applications then become private from the moment they are created, with the ability to specify whether the policy will cover preview traffic, production traffic, or both.
The previews-only option may be suitable for applications intended to remain public in production while preventing development versions from being exposed. Cloudflare also allows the account policy to be overridden for a specific Worker application if it is intended to be public.
Those who do not need a comprehensive policy can apply Access directly to a single Worker. The new Access tab in the Worker interface displays the policies applicable to the application. When more than one policy exists, the most specific policy takes precedence, in the following order: hostname policies, then Worker policies, then account policies.
User Identity Inside Application Code
Access also enables the identity of the user sending each request to the application to be known, including the user's email address, name, and groups. Cloudflare says this data can be used to personalize content, enforce permissions, or log activity for each user.
Identity information appears in the Worker's ctx context object, specifically through ctx.access. The application can call ctx.access.getIdentity() to obtain the identity of the authenticated user without having to implement JSON Web Token verification manually, such as parsing the token, verifying its signature, and extracting its claims.
Access supports connecting the organization's existing identity provider, and access can also be restricted by specific email addresses, email domains, or groups. For agents, access can be granted through service tokens.
Local Testing and Internal Platforms
Identity behavior can be tested locally using wrangler dev by adding an Access configuration to the wrangler.jsonc file to simulate an authenticated user. This allows the developer to change the email address in the configuration and verify that the appropriate content is displayed for each user before deployment.
Cloudflare also released an open-source example of an internal platform that enables static websites to be deployed through drag and drop, with every deployed Worker private by default. This architecture uses Workers for Platforms, where application traffic within the namespace passes through a single distributed Worker. When an Access policy is placed on that Worker, applications deployed through it become private by default.
Availability and Technical Architecture
The feature is now available to everyone through the dashboard, with Cloudflare Access for Workers documentation provided to get started. The new capability is based on FL2, a modular proxy built with Rust that runs Cloudflare's edge infrastructure.
To enable Access at the Worker level instead of the hostname level, Cloudflare separated Workers routing from its execution and moved routing logic to a stage preceding Access. The company explains that the modular FL2 system, with its defined modules and ordered stages, helped it manage this change because each component declares its inputs and outputs consistently, allowing the compiler to detect improper interactions between stages during the restructuring.