[GH-ISSUE #361] Dev-origin / `allowedDevOrigins` protection blocks cross-origin requests in production Cloudflare Worker deployments #81

New issue

Closed

opened 2026-05-06 12:37:03 +02:00 by BreizhHardware · 0 comments

BreizhHardware commented

2026-05-06 12:37:03 +02:00

Owner

Originally created by @sindhukhrisna on GitHub (Mar 9, 2026).
Original GitHub issue: https://github.com/cloudflare/vinext/issues/361

Environment

vinext version: Latest (0.0.25)
Hosting: Cloudflare Workers
Production URL: https://example.com
Auth Production URL: https://auth.example.com
Config excerpt:

const nextConfig = {
  allowedDevOrigins: [
    "example.com",
    "*.example.com",
    "https://example.com",
    "https://*.example.com"
  ],
};

Problem Statement

When deploying a vinext app to Cloudflare Workers (production, not dev), all cross-origin requests from the production domain (e.g., from https://example.com to https://auth.example.com/api/auth/get-session) are blocked, with the server responding:

[vinext] Blocked cross-origin request from "https://example.com" to /api/auth/get-session. To allow this origin, add it to allowedDevOrigins in next.config.js.

This error occurs in PRODUCTION, not during local development.
The same codebase with identical CORS settings works on Next.js but not in vinext on Cloudflare Workers.
Adding the production domain to allowedDevOrigins does not resolve or make sense for production environments.

Expected Behavior

vinext should NOT apply dev-origin protection (allowedDevOrigins, __validateDevRequestOrigin) to production builds/workers.
CORS policy for production should be governed by standard CORS or experimental.serverActions.allowedOrigins, not the dev-origin surface.
No blocking of production requests from the same origin should occur, and no prompt to add production origin to allowedDevOrigins should be shown/required.

Actual Behavior

__validateDevRequestOrigin runs in the deployed Worker, causing valid same-origin production requests to be blocked.
The error message still recommends adding the production domain to allowedDevOrigins, which is a dev-only config.

Steps to Reproduce

Deploy a vinext app to Cloudflare Workers with multiple production domain (e.g., https://example.com and https://auth.example.com).
Use a modern browser to make a cross-origin fetch (or even same-origin, depending on Worker header processing) to an API route (such as https://auth.example.com/api/auth/get-session).
Observe 403 errors and dev-origin error messages in the Worker logs/responses.

Notes

This issue does not occur in pure Next.js deployments, only with vinext on Cloudflare Workers.
Local development works as expected.
The code check for dev-origin protection (__validateDevRequestOrigin) is included in the Worker entry but should not run in production.

Originally created by @sindhukhrisna on GitHub (Mar 9, 2026). Original GitHub issue: https://github.com/cloudflare/vinext/issues/361 ### Environment - **vinext version:** Latest (0.0.25) - **Hosting:** Cloudflare Workers - **Production URL:** https://example.com - **Auth Production URL:** https://auth.example.com - **Config excerpt:** ```js const nextConfig = { allowedDevOrigins: [ "example.com", "*.example.com", "https://example.com", "https://*.example.com" ], }; ``` ### Problem Statement When deploying a vinext app to Cloudflare Workers (production, **not** dev), all cross-origin requests from the production domain (e.g., from `https://example.com` to `https://auth.example.com/api/auth/get-session`) are blocked, with the server responding: ``` [vinext] Blocked cross-origin request from "https://example.com" to /api/auth/get-session. To allow this origin, add it to allowedDevOrigins in next.config.js. ``` - **This error occurs in PRODUCTION, not during local development.** - The same codebase with identical CORS settings works on Next.js but not in vinext on Cloudflare Workers. - Adding the production domain to `allowedDevOrigins` does not resolve or make sense for production environments. ### Expected Behavior - vinext should NOT apply dev-origin protection (`allowedDevOrigins`, `__validateDevRequestOrigin`) to production builds/workers. - CORS policy for production should be governed by standard CORS or `experimental.serverActions.allowedOrigins`, not the dev-origin surface. - No blocking of production requests from the same origin should occur, and no prompt to add production origin to `allowedDevOrigins` should be shown/required. ### Actual Behavior - `__validateDevRequestOrigin` runs in the deployed Worker, causing valid same-origin production requests to be blocked. - The error message still recommends adding the production domain to `allowedDevOrigins`, which is a dev-only config. ### Steps to Reproduce 1. Deploy a vinext app to Cloudflare Workers with multiple production domain (e.g., https://example.com and https://auth.example.com). 2. Use a modern browser to make a cross-origin fetch (or even same-origin, depending on Worker header processing) to an API route (such as `https://auth.example.com/api/auth/get-session`). 3. Observe 403 errors and dev-origin error messages in the Worker logs/responses. ### Notes - This issue **does not occur in pure Next.js** deployments, only with vinext on Cloudflare Workers. - Local development works as expected. - The code check for dev-origin protection (`__validateDevRequestOrigin`) is included in the Worker entry but should not run in production.