14.2.3 serverActions allowedOrigins not working

[adeturner]

Summary

serverActions.allowedOrigins isnt working for me. Please can you advise what I'm missing?

The architecture is nginx > nextjs in Azure Container Apps. Only nginx is exposed on mysubdomain.domain.com. nginx proxies requests to nextjs using the ACA internal hostname. This results in an error:

`x-forwarded-host` header with value `internal_aca_host` does not match 
`origin` header with value `mysubdomain.domain.com` from a forwarded Server Actions request. Aborting the action.

I tried upgrading to 14.2.3.

Then I realised my original next.config.js wasnt being picked up so I converted it to next.config.mjs. I tested to make sure it was being picked up and it is (the upgrade resulted in some obsolete values)

I looked at the nextjs code, and decided that the only possibility is that serverActions.allowedOrigins is still not being populated.

I wrote a test using the function code from the repo source, and it worked fine.

Any ideas you have would be amazing. Thanks!

next.config.mjs:

/** @type {import('next').NextConfig} */

const nextConfig = {
  experimental: {
    serverActions: {
      allowedOrigins: ['*.domain.com', 'domain.com', 'mysubdomain.domain.com'],
    },
  },
}

export default nextConfig;

Additional information

No response

Example

No response

[adeturner]

I have a workaround in NGINX: proxy_set_header X-Forwarded-Host $host;. The security implications are a little unclear if anyone can comment.

Having lost a couple of days on this I suspect (but cannot entirely prove) that in the nextjs code the serverActions.allowedOrigins is not populated at the time it is needed in the call to isCsrfOriginAllowed

[HeikkiYlipaavalniemi]

We are encountering the same thing in Azure environment where the next.js application is not able to communicate because of the x-forwarded-host header. We did also try the allowedOrigins fix but it didn't work. The nginx fix also worked for us but would be nice to get the recommended fix from next.js working also.

[jnm733]

I have now the same problem when I update my project to Next.js 15. With version 14 is working correctly.

[devjmetivier]

I wouldn't recommend this for a final, production application, but you could get by temporarily by just commenting out that else clause. That way it never throws the error. I believe you'll need to do this in two separate dist files.

next.js/packages/next/src/server/app-render/action-handler.ts

Lines 457 to 506 in 04571f3

	} else {
	if (host) {
	// This seems to be an CSRF attack. We should not proceed the action.
	console.error(
	`\`${
	host.type
	}\` header with value \`${limitUntrustedHeaderValueForLogs(
	host.value
	)}\` does not match \`origin\` header with value \`${limitUntrustedHeaderValueForLogs(
	originDomain
	)}\` from a forwarded Server Actions request. Aborting the action.`
	)
	} else {
	// This is an attack. We should not proceed the action.
	console.error(
	`\`x-forwarded-host\` or \`host\` headers are not provided. One of these is needed to compare the \`origin\` header from a forwarded Server Actions request. Aborting the action.`
	)
	}
	const error = new Error('Invalid Server Actions request.')
	if (isFetchAction) {
	res.statusCode = 500
	await Promise.all(
	Object.values(staticGenerationStore.pendingRevalidates || [])
	)
	const promise = Promise.reject(error)
	try {
	// we need to await the promise to trigger the rejection early
	// so that it's already handled by the time we call
	// the RSC runtime. Otherwise, it will throw an unhandled
	// promise rejection error in the renderer.
	await promise
	} catch {
	// swallow error, it's gonna be handled on the client
	}
	return {
	type: 'done',
	result: await generateFlight(ctx, {
	actionResult: promise,
	// if the page was not revalidated, we can skip the rendering the flight tree
	skipFlight: !staticGenerationStore.pathWasRevalidated,
	}),
	}
	}
	throw error
	}

[devjmetivier]

I should also clarify that this fix is for Next 15. I'm specifically on 15.0.3

[devjmetivier]

Update: I found out I was actually configuring this wrong.

In multi-zone architectures, you must explicitly allow the user-facing origin. I misunderstood this initially.

You'll need to configure allowedOrigins in your project(s) that is not the user-facing origin. And if that's not clear:

www.example.com  <- user-facing origin

sub.example.com. <- needs `allowedOrigins` configured with `www.example.com`
sub2.example.com. <- needs `allowedOrigins` configured with `www.example.com`

I previously had this configured the other way around. Hope this helps.

[benjamingorman]

Next.js version 15.0.3
Echoing what @devjmetivier said, the fix here is a little non-intuitive.

In my case I have a setup running on AWS with:

• ECS service running Next.js
• AWS application load balancer routing with ECS service as target
• A public domain name (mycompany.com) with a CNAME to the load balancer DNS name

The error received is:

`x-forwarded-host` header with value `my-alb-1123514176.eu-west-1.elb.amazonaws.com` does not match `origin` header with value `mycompany.com` from a forwarded Server Actions request…

The fix for me was (in next.config.ts) to include both the public DNS name and the alb DNS name in allowedOrigins

let nextConfig: NextConfig = {
	output: "standalone",
	experimental: {
		serverActions: {
			// Otherwise server actions don't work in AWS
			// https://github.com/vercel/next.js/issues/58295
			allowedOrigins: [
				"my-alb-1123514176.eu-west-1.elb.amazonaws.com",
				"mycompany.com",
			],
		},
	},
};
export default nextConfig;

This is not mentioned in the other main thread about this issue #58295
IMO It should be clarified in the docs here https://nextjs.org/docs/app/api-reference/config/next-config-js/serverActions that both DNS names are required in this situation.