Secure all your internal vibe-coded applications — in one click
AI-driven development makes it easy for employees to deploy applications, but also increases the risk of unintentionally exposing company data. Cloudflare’s new Access integration for Workers makes applications private by default at the Worker or account level, regardless of how they are reached. It also exposes authenticated user identity directly in Worker code and supports private-by-default internal deployment platforms. ## Worker-Level Access Protection - Access authentication is enforced before requests reach application code. - Protection applies across custom domains, routes, `workers.dev` subdomains, and preview URLs. - Policies can cover: - Preview deployments only - Every hostname associated with a Worker - Attaching policies to the Worker eliminates the need to update Access settings whenever a new domain is added. - Existing identity providers, email addresses, domains, groups, and service tokens can control access. ## Account-Wide Private Defaults - An account-level policy automatically protects all current and future Workers. - Organizations can protect preview traffic, production traffic, or both. - Public Workers can explicitly bypass the account-wide policy. - For individual applications, Worker policies provide targeted protection. - When multiple policies apply, precedence is: - Hostname policies - Worker policies - Account policies ## Accessing User Identity in Worker Code - Authenticated requests expose identity through `ctx.access`. - `ctx.access.getIdentity()` returns information such as: - Email address - Name - Groups - Developers no longer need to parse, validate, and extract claims from Access JWTs manually. - Applications can use this identity for personalization, authorization, and per-user logging. - Code should handle requests without Access metadata, for example by returning a `403` response. ## Local Development and Testing - `wrangler dev` can simulate authenticated users locally. - An `access.dev` block in `wrangler.jsonc` defines a test audience and identity: ```json { "access": { "dev": { "aud": "my-app", "identity": { "email": "admin@company.com" } } } } ``` - Developers can change the configured email to test different user experiences without repeatedly deploying and authenticating through Access. ## Private Internal Deployment Platforms - Workers for Platforms can host many applications inside a namespace. - Traffic is routed through a shared dispatch Worker. - Protecting the dispatch Worker with Access makes every application deployed through it private by default. - Cloudflare provides an open-source example of an internal drag-and-drop deployment platform using this model. ## Infrastructure Behind the Feature - The capability relies on FL2, Cloudflare’s Rust-based modular proxy. - Workers routing had to be separated from execution so Cloudflare could determine the destination Worker before applying Access. - This routing change would have been more difficult in the older NGINX- and Lua-based FL1 architecture. Cloudflare’s approach shifts application security from an optional developer-configured step to an organizational default. Teams deploying internal or experimental Workers should use account-level or dispatch-level Access policies, while using Worker-level policies and local identity simulation for application-specific control and testing.
Read original(opens in new tab)
