## Securing Cloudflare Workers: A New Era of Application Security
In today’s fast-paced development environment, cloud platforms have empowered employees across all teams to build and deploy applications faster than ever before. However, this speed comes with a significant concern for Chief Information Security Officers (CISOs): any employee can now build an application, deploy it to the public internet, and inadvertently expose internal work or company data.
Cloudflare has responded to this challenge by launching new tools designed to make it easy to keep applications hosted on Workers private. These innovative solutions ensure that your applications are behind your company login by default, without relying on each developer to set up security measures individually.
### Key Features of the New Security Tools
– **Account-Level Policies**: Set a policy at the account level to ensure that all preview and production deployments are behind your company login by default.
– **Application-Specific Policies**: Apply authentication on a single application to enforce it on every domain associated with it, regardless of deployment method.
– **User Visibility**: Gain insights into who visits your application by accessing authenticated user details such as email, name, and groups directly within your code—no JWT validation required.
– **Internal Platform Deployment**: Deploy an internal platform where every deployment is private by default, with an open-sourced example available.
### How Access on Workers Works
When Access is enabled on a Worker, Cloudflare enforces authentication before any request reaches your application code. This ensures that regardless of how the request arrives—whether through a custom domain, a route, a workers.dev subdomain, or a preview URL—the user must authenticate first.
Previously, configuring access required setting up policies at the hostname level, which meant updating Access policies for each domain. Now, policies are attached directly to the Worker, automatically protecting any associated domain or URL. You can choose to protect preview URLs only or all hostnames, giving you flexible control over user authentication.
### Maintaining Flexibility
While account-wide policies provide default security, there may be instances where specific Workers need to be public. In such cases, you can bypass the account-wide policy for individual Workers, ensuring that only the necessary applications remain accessible.
The new Access tab in the Worker view displays which policies apply to each application, with more specific policies taking precedence over general ones.
### Enhancing User Visibility and Security
When Access protects your Worker, you can obtain information about each request’s user, including their email, name, and groups. This data can be utilized to personalize user experiences, enforce permissions, or log activity.
Access integrates seamlessly with the Worker’s context object, providing authenticated user identity without the need for manual JWT validation:
“`javascript
export default {
async fetch(request, env, ctx) {
if (!ctx.access) {
return new Response(“Access required”, { status: 403 });
}
const identity = await ctx.access.getIdentity();
const email = identity?.email ?? “unknown”;
return new Response(`Hello, ${email}`);
},
};
“`
### Testing Locally Before Deployment
Developers can simulate authenticated users when testing locally with `wrangler dev`. By adding an access block to the `wrangler.jsonc` file, you can verify that your Worker responds correctly to authenticated requests without repeated deployments:
“`json
{
“access”: {
“dev”: {
“aud”: “my-app”,
“identity”: { “email”: “admin@company.com” }
}
}
}
“`
### Building a Private-by-Default Internal Platform
For organizations managing internal platforms where employees can deploy applications, ensuring every application is private by default is crucial. Workers for Platforms allows you to deploy Workers at scale within a namespace, with all traffic routed through a single entry point—the dispatch Worker.
By setting an Access policy on the dispatch Worker, every Worker deployed through it becomes private automatically.
For a hands-on experience, consider deploying Cloudflare’s open-source example of an internal drag-and-drop deployment platform, which demonstrates these security features in action.
### Underlying Architecture
This new security functionality is built on FL2, Cloudflare’s Rust-based modular proxy. The separation of routing from execution in FL2 allows for efficient and secure request handling, ensuring that Access policies are enforced before application logic processes requests.
### Getting Started
These new security features are available to all users. You can begin securing your Workers today through the Cloudflare dashboard or by consulting the [Cloudflare Access for Workers documentation](https://developers.cloudflare.com/workers/runtime-apis/access/).
—
## FAQ
### What problem do these new tools solve?
The tools address the security risks that arise when employees can quickly build and deploy applications, potentially exposing sensitive company data. By enforcing authentication by default, they ensure applications are accessible only to authorized users.
### How can I enforce authentication for all my Workers?
You can set an account-level policy in the Cloudflare dashboard to require authentication for all preview and production deployments across every Worker in your account.
### Can I make a specific Worker public while keeping others private?
Yes, you can bypass the account-wide policy for individual Workers, allowing specific applications to remain publicly accessible.
### How does user visibility work with Access enabled?
When Access is active, you can retrieve detailed information about authenticated users—including email, name, and groups—directly in your Worker’s context, facilitating personalized experiences and enhanced security monitoring.
### How can developers test authentication locally?
Using `wrangler dev`, developers can simulate authenticated requests by configuring an access block in `wrangler.jsonc`, specifying test identities to validate Worker behavior without frequent deployments.
—
## Conclusion
Cloudflare’s latest security tools for Workers represent a significant advancement in application protection, enabling organizations to maintain rapid development cycles without compromising security. By automating authentication requirements and providing granular control over access policies, these tools help safeguard sensitive data while fostering innovation.
As the digital landscape continues to evolve, embracing such robust security measures will be essential for organizations looking to protect their assets and maintain trust with their users. Whether you’re managing internal platforms or deploying customer-facing applications, these new capabilities ensure that security remains seamless, scalable, and straightforward.
