JA EN
shiichan

You Can Now Protect Every Cloudflare Worker with Access at Once!

Cloudflare Changelog ★★★★ View Markdown
#cloudflare#serverless#security

Hey, it's me! Today I found a security update for Cloudflare Workers that's small but really handy. I was surprised how much simpler it makes protecting your Workers, so let me walk you through it!

Cloudflare Changelog developers.cloudflare.com

What was announced?

Cloudflare's Changelog introduced two new ways to apply Cloudflare Access to your Workers.

  • You can now attach an Access policy to a single Worker, or to every Worker in your account at once
  • You can choose to protect preview deployments only, or both previews and production

The story so far

Before this, if a Worker was reachable through a route, a custom domain, and a workers.dev URL, you had to add each one to an Access application yourself, and keep that list in sync every time a route or domain changed. That's easy to forget, and forgetting means a gap in your protection.

What changes

Now you can attach the policy to the Worker itself. Every domain and preview URL tied to that Worker stays protected automatically, even as routes and domains change — no more manual list to maintain.

On top of that, you can set every Worker in your account, new or existing, to be private by default. If a specific Worker should stay public, you just add a Worker-level bypass for it. You can control who's allowed to sign in by Cloudflare account membership, email address, or email domain, and for more advanced policies you can edit them directly in Zero Trust.

Dive Deep

For Workers with Access enabled, every authenticated request now carries ctx.access. Calling ctx.access.getIdentity() gives you the signed-in user's email, name, and groups, so you don't need to write your own JWT validation.

export default {
  async fetch(request, env, ctx) {
    if (!ctx.access) {
      return new Response("Access did not run", { status: 401 });
    }

    const identity = await ctx.access.getIdentity();
    return Response.json({ aud: ctx.access.aud, email: identity?.email });
  },
};

You can also test the sign-in flow locally with wrangler dev, by adding an access.dev block to your wrangler.jsonc.

{
  "access": {
    "dev": {
      "aud": "my-app",
      "identity": { "email": "admin@example.com" }
    }
  }
}

You can view and manage all your Access policies from the Access tab under Workers & Pages in the dashboard, and configuration is also available through the Workers API.

Wrap-up

  • You can now attach an Access policy to a single Worker or to your whole account at once
  • The policy follows the Worker itself, so it keeps protecting new or changed domains and routes automatically
  • ctx.access.getIdentity() gets you the authenticated user's info without hand-rolled JWT checks
  • wrangler.jsonc lets you test the sign-in flow locally during development

If you run internal tools or staging environments on Cloudflare Workers, this update is worth a look!

Related posts