`request.url` mismatch when app is loaded in iframe using storage access headers

[mrksbnch]

I'm using React Router as a...

framework

Reproduction

Go to https://github.com/mrksbnch/react-router-storage-access-headers and follow the steps in the README.md, or refer to the instructions below.
To test this, open the application in Chrome and enable the following flag:
chrome://flags/#test-third-party-cookie-phaseout.

1. Run npm install to install dependencies.
2. Run npm run incorrect to start the app at http://localhost:3000 and serve a static iframe.html file located at /public/iframe.html via http://localhost:4000.
3. Open the iframe at http://localhost:4000.
4. Grant storage access by clicking the button inside the iframe.
5. You should see the URL from both window.location.href and request.url (exposed via the loader); these should be identical.
6. Reload the page.

---

As background information, this article about Storage Access Headers explains the use cases and how the mechanism works.

The main use case is allowing your app to be loaded inside an iframe.
This typically comes with certain limitations (especially with cookies) which are treated as third-party cookies.
Most browsers already block third-party cookies, and Chrome is following the same path.

There are a few workarounds to these limitations, such as using partitioned cookies or the Storage Access API.
The Storage Access API allows an application to access the same cookies available outside of an iframe (assuming the user has granted access).

In the past, requesting storage access was only possible on the client side, even if the user had already granted access. With Storage Access Headers, it's now possible to request storage access on the server side, assuming that the user has granted access (on the client) once before.

System Info

System:
    OS: macOS 14.6.1
    CPU: (8) arm64 Apple M1
    Memory: 117.17 MB / 8.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 23.7.0 - /opt/homebrew/bin/node
    npm: 10.9.2 - /opt/homebrew/bin/npm
    pnpm: 9.15.0 - ~/Library/pnpm/pnpm
  Browsers:
    Chrome: 136.0.7103.114
    Safari: 17.6
  npmPackages:
    @react-router/dev: ^7.6.0 => 7.6.0 
    @react-router/node: ^7.6.0 => 7.6.0 
    @react-router/serve: ^7.6.0 => 7.6.0 
    react-router: ^7.6.0 => 7.6.0 
    vite: ^6.3.3 => 6.3.5

Used Package Manager

npm

Expected Behavior

The URLs shown in the demo application (window.location.href and request.url (from the loader)) should be the same.

Even when the page is loaded inside an iframe, the server-side URL should not reflect or expose the parent frame’s URL.

Actual Behavior

The URL from the loader (request.url) incorrectly shows the URL of the parent page.
It appears that the React Router dev server sets the URL incorrectly in this case.

Note:

• The HTTP Host header is correctly set to the actual application’s domain.
• In the demo, the path is /. If the page was served at a different path, e.g., /page, request.url would still report the hostname of the parent page but show the correct path from the iframe.

---

I'm not sure if there are any workarounds when using the React Router dev server. It might work correctly with a custom Express server because my Express-based example (linked in the repo) behaves as expected.

[timdorr]

I think the issue may be using the localhost context. I forked the project here on CodeSandbox and it's showing this:

From Client Side
{
  "url": "https://6xnf44-3000.csb.app/?embed=123"
}
From Server Side
{
  "url": "http://6xnf44-3000.csb.app/?embed=123"
}

Other than the HTTPS proxying that's going on to change the protocol, the origins are the same. You might try using localtest.me or lvh.me to get around the localhost context issue. It's treated differently for a number of different things.

Outside of that, I don't think this is something we can fix on our end. The request is whatever the browser reports as the current URL for the page. If that's different due to a security feature in iframes, there is likely nothing we can do on our end to control that.

[mrksbnch]

@timdorr I was suspecting the same in the beginning and I'm aware that localhost has some specific behavior. That's why I created the additional Express example (also included in the repo) which works just fine on localhost. That makes me believe that the issue isn't localhost. If it was why would it work fine if you use something like Express?

I'm not sure how the React Router Vite plugin works but it could potentially also be something in Vite.

[mrksbnch]

@timdorr

TLDR: I did a few more tests and it seems this is not a localhost or Vite issue. It does work fine on localhost provided that the parent URL is considered a secure context, so by using a self-signed certificate for localhost or using 127.0.0.1 as a parent domain. I see that you closed this issue but I would like to understand why you think this is not a react router issue?

Other than the Express app I mentioned, I also created a Sveltekit demo here because it's also using Vite as a bundler. If you run this locally following the steps in the README.me...

1. Run `npm install` to install dependencies.
2. Run `npm run correct` to start the app at [http://localhost:3000](http://localhost:3000) and serve a static `iframe.html` file located at `/public/iframe.html` via [http://127.0.0.1:4000](http://127.0.0.1:4000).
3. Open the iframe at [http://127.0.0.1:4000](http://127.0.0.1:4000).
4. Grant storage access by clicking the button inside the iframe.
5. You should see the URL from both `window.location.href` and `request.url` (exposed from the loader) which should be identical.
6. Reload the page (the URLs should still match).

you can see that this work just fine without any mismatch, even on localhost.

---

I also tried services like lvh.me or localtest.me but they show the same incorrect results for the react-router setup. They show:

From Client Side
{
  "url": "http://localhost:3000/?embed"
}
From Server Side
{
  "url": "https://lvh.me:4000/?embed="
}

If you want to test this yourself, you need to slightly adapt iframe.js in order to make the browser see the parent URL as a secure context:

1. Create a self-signed certificate for lvh.me, e.g. using "mkcert": mkcert -install, mkcert "*.lvh.me" "lvh.me"
2. Adjust iframe.js to spin up a HTTPS server:

import fs from "fs";
import https from "https";
import express from "express";
import path from "path";
import { fileURLToPath } from "url";

const PORT = 4000;

let app = express();

let __filename = fileURLToPath(import.meta.url);
let __dirname = path.dirname(__filename);

app.get("/", (req, res) => {
  res.sendFile(path.join(__dirname, "public", "iframe.html"));
});

https
  .createServer(
    {
      key: fs.readFileSync("./_wildcard.lvh.me+1-key.pem"),
      cert: fs.readFileSync("./_wildcard.lvh.me+1.pem"),
    },
    app
  )
  .listen(PORT, () => {
    console.log(`HTTPS server running at https://lvh.me:${PORT}`);
  });

[mrksbnch]

@timdorr I had a bit time this evening to check what causes this issue in react router and found the cause [in fromNodeRequest] (https://github.com/remix-run/react-router/blob/main/packages/react-router-dev/vite/node-adapter.ts#L51).

I'm not exactly sure why you use the Origin header to get the full path in a Node context but my assumption is to also infer the protocol which is not part of Host. The issue with relying on Origin is that for the new storage access headers (if set), Origin is set to the parent URL. I need to do a few more tests but the simplest fix would thus be to change the line mentioned above to:

let origin =
    nodeReq.headers.origin &&
    "null" !== nodeReq.headers.origin &&
    nodeReq.headers["sec-fetch-storage-access"] == undefined
      ? nodeReq.headers.origin
      : `http://${nodeReq.headers.host}`;

Not necessary part of this issue but in order to better infer the protocol, something like this could be used as an alternative:

// `x-forwarded-proto` could be set to a list of protocols or to other values than "https"
  let protocol =
    nodeReq.headers["x-forwarded-proto"]?.split(",")[0] === "https" ? "https" : "http";
  let origin =
    nodeReq.headers.origin &&
    nodeReq.headers.origin !== "null" &&
    nodeReq.headers["sec-fetch-storage-access"] === undefined
      ? nodeReq.headers.origin
      : `${protocol}://${nodeReq.headers.host}`;

What do you think?

---

@brophdawg11 Sorry for the ping but this issue is closed and I'm not sure why (I also can't reopen it).