Support allowedDevOrigins separately from serverActions.allowedOrigins

[JaredStowell]

Summary

Parse and wire allowedDevOrigins as its own config surface instead of reusing experimental.serverActions.allowedOrigins.

This fixes the dev-origin enforcement so the dev server allowlist does not widen or narrow trust boundaries based on server action CSRF config.

Changes

• add allowedDevOrigins to NextConfig and ResolvedNextConfig
• parse top-level allowedDevOrigins in resolveNextConfig()
• use allowedDevOrigins for Pages Router dev-origin checks
• pass allowedDevOrigins into the App Router virtual RSC entry
• keep App Router server action CSRF checks wired to experimental.serverActions.allowedOrigins
• update vinext check to report allowedDevOrigins as supported

Tests

• add parser tests for allowedDevOrigins defaults and separation from serverActions.allowedOrigins
• add Pages Router dev-server integration coverage test/development/basic/allowed-dev-origins.test.ts
• add App Router codegen/plugin wiring tests to verify allowedDevOrigins and allowedOrigins remain distinct
• add vinext check coverage for allowedDevOrigins

Verification

• pnpm test tests/check.test.ts -t "allowedDevOrigins|experimental.serverActions|next.config"
• pnpm test tests/shims.test.ts -t "allowedDevOrigins|serverActionsAllowedOrigins"
• pnpm test tests/app-router.test.ts -t "loads allowedDevOrigins from next.config into the virtual RSC entry|keeps allowedDevOrigins separate from allowedOrigins|embeds allowedDevOrigins"
• pnpm test tests/pages-router.test.ts -t "Pages Router allowedDevOrigins config"
• pnpm test tests/dev-origin-check.test.ts

[james-elicx]

/bigbonk review

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vinext@337

commit: 28ce2a8

[ask-bonk]

Review: Support allowedDevOrigins separately from serverActions.allowedOrigins

This is a clean, well-scoped fix that correctly separates two distinct trust boundaries that were previously conflated. The change matches Next.js's upstream behavior where allowedDevOrigins is a top-level config option (see config-shared.ts in Next.js) and experimental.serverActions.allowedOrigins is a separate CSRF setting.

What the PR does right

1. Config parsing — allowedDevOrigins is correctly parsed as a top-level field in resolveNextConfig(), with Array.isArray() validation and an empty-array default. The null-config path also correctly initializes it.

2. Separation of concerns — The three index.ts call sites that pass origins to validateDevRequest() now correctly use nextConfig?.allowedDevOrigins (dev server cross-origin allowlist), while the RSC entry's CSRF validation for server actions continues to use nextConfig?.serverActionsAllowedOrigins. These are two different security checks with different semantics.

3. App Router wiring — The generateRscEntry() call correctly passes allowedDevOrigins and allowedOrigins as separate fields. In the generated RSC entry code, __allowedDevOrigins (from generateDevOriginCheckCode()) and __allowedOrigins (for __validateCsrfOrigin()) remain distinct variables.

4. Prod server is unaffected — allowedDevOrigins is correctly absent from prod-server.ts and worker-entry.ts. This is a dev-only setting.

5. Test coverage — Good coverage across all layers: config parsing (defaults, separation, null input), vinext check detection, App Router codegen (both unit and integration), and Pages Router dev server integration with a test that verifies serverActions.allowedOrigins does NOT grant dev server access.

6. Next.js test porting — The Pages Router integration test correctly references the upstream Next.js test (test/development/basic/allowed-dev-origins.test.ts) per the project's contribution guidelines.

Minor observations (non-blocking)

• The AppRouterConfig JSDoc update in app-dev-server.ts:32 is a nice touch — the old comment was misleading ("from serverActionsAllowedOrigins or custom config").
• The vinext check change correctly adds allowedDevOrigins to both the CONFIG_SUPPORT map and the configOptions scan list.

All tests pass. LGTM.

[ask-bonk]

Review submitted. Here's a summary of what I found:

Approved — This is a well-implemented fix that correctly separates two distinct security trust boundaries:

1. allowedDevOrigins (top-level config) — controls which origins can access the dev server
2. experimental.serverActions.allowedOrigins — controls CSRF validation for server actions

Previously, serverActionsAllowedOrigins was being used for both purposes, which meant that adding a trusted origin for server action CSRF checks would also widen the dev server's cross-origin allowlist (and vice versa). The fix matches Next.js's upstream API where these are separate config surfaces.

All 8 changed files are consistent, the prod server is correctly unaffected (dev-only setting), and test coverage is thorough across config parsing, App Router codegen, Pages Router integration, and vinext check.

github run