Cloudflare Access Now Secures All Cloudflare Workers Applications by Default
Cloudflare has enhanced its Access product to automatically protect all applications hosted on its Workers platform, simplifying security for employee-built internal tools.
Cloudflare announced a significant enhancement to its Cloudflare Access product, now enabling it to protect applications hosted on Cloudflare Workers by default. This new capability aims to address the growing concern among CISOs regarding the potential for employee-created applications to inadvertently expose internal data or company secrets. By applying Cloudflare Access at the account or application level, organizations can ensure that all Workers-based applications are secured behind their company's login credentials before any requests reach the application code.
The new functionality allows administrators to set account-wide policies that automatically enforce authentication for all preview and production deployments of Workers applications. This means that any new application or update deployed to the Workers platform will be private by default, requiring users to authenticate via their company login. For organizations with many developers building internal tools, this removes the burden of ensuring each individual developer manually configures security settings, thereby reducing the risk of accidental exposure.
Previously, securing Workers applications required configuring Access policies at the hostname level for each domain associated with a Worker. This meant that adding a new custom domain or route could lead to an unauthenticated access point if the Access policy was not updated promptly. The new approach attaches the policy directly to the Worker itself, ensuring that any domain or URL linked to that Worker is automatically protected. Administrators can choose to protect only preview URLs, all hostnames, or specific combinations, offering granular control over the security posture.
Beyond default protection, Cloudflare Access for Workers now provides richer user identity information directly within the application code. When Access is enabled, authenticated user details such as email, name, and group memberships are made available through the Worker's context object (ctx.access). This eliminates the need for developers to manually validate JSON Web Tokens (JWTs), streamlining the process of personalizing user experiences, enforcing permissions, or logging activity based on who is accessing the application.
To further aid developers, Cloudflare has integrated this functionality with its local development tools. Using wrangler dev, developers can simulate authenticated users by configuring mock identities in wrangler.jsonc. This allows for local testing of user-specific content and permissions without the need for repeated deployments and manual sign-ins, accelerating the development cycle.
The platform also introduces a new option for managing internal application platforms. By setting an Access policy on a dispatch Worker within a Workers for Platforms setup, all applications deployed through that entry point become private by default. This is particularly useful for internal developer platforms where employees can prototype and deploy applications without requiring individual security configurations for each one.
This update represents a significant step forward in securing the rapidly expanding landscape of internal applications built on serverless platforms. By making robust authentication a default feature, Cloudflare aims to empower organizations to embrace developer agility without compromising security, ensuring that internal data remains protected even as development speeds increase.