Cross-site remote requests forbidden error when using remote functions in production deployment

[Spikeysanju]

Describe the bug

Issue Summary

I'm encountering a 403 error with the message "Cross-site remote requests are forbidden" when using SvelteKit's remote functions feature in a production deployment. The remote function works correctly in development but fails when deployed to Railway.

Environment

• SvelteKit version: 2.37.0
• Svelte version: 5.38.6
• Deployment platform: Railway
• Adapter: @sveltejs/adapter-node (5.3.1)

Reproduction

Steps to Reproduce

1. Create a simple remote function using command from $app/server:

// src/lib/remote/ai.remote.ts
import { command } from '$app/server';

export const simulateAIGeneration = command('unchecked', async (payload) => {
    return {
        enhancedText: 'This is a simulated AI generation: ' + payload.text
    };
});

2. Use the remote function in a Svelte component:

<script lang="ts">
import { simulateAIGeneration } from '../lib/remote/ai.remote';

let inputText = '';
let enhancedText = '';
let loading = false;
let error = '';

async function handleEnhance() {
    loading = true;
    error = '';
    enhancedText = '';
    try {
        const result = await simulateAIGeneration({ text: inputText });
        enhancedText = result.enhancedText;
    } catch (e) {
        if (e instanceof Error) {
            error = e.message;
        } else {
            error = 'Failed to enhance text.';
        }
    } finally {
        loading = false;
    }
}
</script>

3. Deploy to Railway using the provided Dockerfile and docker-compose.yml
4. Access the deployed application and try to use the remote function
5. Observe the 403 error with the response: {"message":"Cross-site remote requests are forbidden"}

Expected Behavior

The remote function should work in production deployment just as it does in development.

Actual Behavior

The remote function call fails with a 403 Forbidden status code and the response:

{"message":"Cross-site remote requests are forbidden"}

Additional Information

Repository: https://github.com/thisuxhq/remotetest
Live Demo: https://remotetest-production.up.railway.app/

The application is a simple text enhancer that demonstrates the issue. The remote function works perfectly in development mode (bun run dev) but fails when deployed to Railway.

Configuration Files

The deployment uses:

• Docker containerization
• @sveltejs/adapter-node for server-side rendering
• Railway as the hosting platform

Logs

{"message":"Cross-site remote requests are forbidden"}

System Info

System:
    OS: macOS 15.1
    CPU: (8) arm64 Apple M1
    Memory: 91.69 MB / 8.00 GB
    Shell: 5.9 - /bin/zsh
Binaries:
    Node: 23.5.0 - /opt/homebrew/bin/node
    npm: 10.9.2 - /opt/homebrew/bin/npm
    bun: 1.1.42 - /opt/homebrew/bin/bun
Browsers:
    Brave Browser: 139.1.81.137
    Safari: 18.1
npmPackages:
    @sveltejs/adapter-node: ^5.3.1 => 5.3.1 
    @sveltejs/kit: ^2.37.0 => 2.37.0 
    @sveltejs/vite-plugin-svelte: ^6.1.3 => 6.1.3 
    svelte: ^5.38.6 => 5.38.6 
    vite: ^7.1.3 => 7.1.3

Severity

blocking all usage of SvelteKit

Additional Information

Questions

1. Is there a specific configuration needed for remote functions to work in production deployments?
2. Are there any CORS or security settings that need to be configured for Railway deployments?
3. Is this a known limitation of remote functions in certain deployment environments?
4. What causes the 403 "Cross-site remote requests are forbidden" error specifically?

Related

This might be related to CORS configuration or security policies in production environments, but the specific 403 error message suggests it's related to SvelteKit's remote functions security implementation.

[Conduitry]

This isn't a CORS thing; it's a CSRF thing. I'm imagining this is because the Node server has the wrong idea of what origin it's being served at - so it doesn't match the Origin header of the requests coming from the browser - and you need to adjust the environment variables mentioned in https://svelte.dev/docs/kit/adapter-node. You can confirm what origin the server thinks it's serving from by logging event.url in a handle hook.

[Spikeysanju]

@Conduitry This is what i got in PROD.

=== Request Debug Info ===
Request URL: http://remotetest-production.up.railway.app/
Origin header: null
Host header: remotetest-production.up.railway-app
Referer header: null
Environment ORIGIN: https://remotetest-production.up.railway-app
Environment NODE_ENV: production
=====

[bytecodemanipulator]

Your request URL protocol is http but it should be https for it to match your ORIGIN. I think you just need to set the PROTOCOL_HEADER environment variable to specify the header that contains the actual request protocol.

[Spikeysanju]

@bytecodemanipulator @Conduitry I ran the test again. Now it's showing HTTPS on both the request URL and the origin, but it still doesn't work.

remotetest  | === Request Debug Info ===
remotetest  | Request URL: https://remotetest-production.up.railway.app
remotetest  | Origin header: null
remotetest  | Host header: remotetest-production.up.railway.app
remotetest  | Referer header: null
remotetest  | Environment ORIGIN: https://remotetest-production.up.railway.app
remotetest  | Environment NODE_ENV: production
remotetest  | X-Forwarded-Proto header: https
remotetest  | X-Forwarded-Host header: remotetest-production.up.railway.app
remotetest  | ================================

[Conduitry]

SvelteKit expects an Origin header to be present on all such requests. Are you using an unusual browser configuration that isn't sending one? Is your hosting environment stripping it before it gets to your app?

[aster-void]

Got the same error on local docker.
It seems like missing ORIGIN environment causes the issue? I don't understand how it works.

for those who encounter this error, here's the quick fix:

ENV ORIGIN=http://localhost:3000 # the domain your app is deployed at

environment info

• runtime: oven/bun:1
• svelte version: 5.39.5
• kit version: 2.43.2

[MohammadBnei]

I have the same problem but only on production.
It's a shame, remote functions clean up my services so nicely. Love this feature !

[frederickmannings]

Having the same issue. Setting origin to localhost does not fix for me.

[aster-void]

Having the same issue. Setting origin to localhost does not fix for me.

My bad, the instruction was unclear. Try your production domain, does it work?

[chunnamwong]

I ran into the same issue while doing E2E tests with Playwright. I was running a production build with Bun inside a Docker container and saw the same error. After looking into the source code, I initially expected the check here to pass. The request includes an Origin header, and the request URL appears to match that origin—for example, http://localhost:3000 making a request to http://localhost:3000/_app/remote/1c7vzy6/createUser. So why wouldn’t it match?

To debug, I printed request_origin and url.origin. It turned out request_origin was http://localhost:3000, but url.origin was https://localhost:3000.

The cause seems to be that the Bun adapter used for production builds always assumes HTTPS.

So the fix is either:

• Run the app behind HTTPS, or
• Set the PROTOCOL_HEADER environment variable so the adapter can infer http.
• More in the documentation

Since this was just a demo app to test Remote Functions with Playwright, I went with the header approach:

.env

PROTOCOL_HEADER=REQUEST-PROTOCOL

Playwright beforeEach

await page.route(`${appUrl}/**`, async (route) => {
	const request = route.request();
	await route.continue({
		headers: {
			...request.headers(),
			'REQUEST-PROTOCOL': 'http', // <-- Append this header on every request
		},
	});
});

This is just a workaround so I can run Playwright tests while keeping HTTP. In practice, it's probably better to set up HTTPS (which is also what the adapter assumes by default).

Hope this helps!

[teemingc]

To debug, I printed request_origin and url.origin. It turned out request_origin was http://localhost:3000, but url.origin was https://localhost:3000.

The cause seems to be that the Bun adapter used for production builds always assumes HTTPS.

It’s probably based on the Node adapter which does the same. The ORIGIN env variable should be set to circumvent this. See https://svelte.dev/docs/kit/adapter-node#Environment-variables-ORIGIN-PROTOCOL_HEADER-HOST_HEADER-and-PORT_HEADER

This has tripped me up before too. At this point, I think it might be better to print a warning message if the ORIGIN var is not set

[Conduitry]

If you're making an app that expects to be run from multiple different domains in a multitenant way, setting ORIGIN would not be desirable, and I don't think we should unconditionally warn about it not being set. I don't know what a good set of conditions for warning would be.

[Stephen10121]

I'm also running into this issue. I use multiple domains for the same service, so I add them to the trusted origins in the svelte.config.js:

const config = {
    ....
    kit: {
		csrf: {
			trustedOrigins: ["https://example.com", "https://api.example.com", "https://www.example.com"]
		},
		experimental: {
			remoteFunctions: true
		}
	}
};

Even the domains that I added to the trusted origins list, dont let me do Cross-site remote requests

[Quacken8]

I ran into the same issue. Same setup: bun in production just doesnt let the command through no matter the ORIGIN env var or what I put in trustedOrigins (including '*')

But I have noticed this seems to be isolated only to the command remote function. query works just fine. So that's a good workaround: just use query for now and don't return anything from it.