Request header 'Referer' is different between Hosted Blazor Webassembly, and non hosted Blazor Webassembly

I've been developing a hobby project in Blazor Webassembly ASP.NET Core hosted using the template Identity Server implementation, and have developed some authorization, which looks at the API calls from Blazor Webassembly, and uses the the request header 'Referer' to authorize.

The user has some subscriptions to some Teams they attend, and they can switch between them.

The URL has the Guid of what team page they are currently on, and when the Blazor Webassembly made an API call to the ASP.NET Core Web API, it would then look at the 'Referer' to find the Guid.

Here is the request header 'Referer' value as in hosted with ASP.NET Core

The 'Referer' value would be

https://localhost:5001/Instructor/{some-guid}.

So from the Guid in the 'Referer', I could know what team the user is trying to get information for. F.ex. a list of members on the team.

This was working well, but because I was migrating to ASP.NET Core 6, and wanted to create a JAMStack setup, I moved to a new setup with standalone Blazor Webassembly, and ASP.NET Core Web API setup.

I have the exact same authorization setup, except I have switched to using Auth0 instead of Identityserver (Duende).

I am also using NSwagStudio to create a client for the HTTP Requests for both the old and new project (and the setup is identical).

My problem now is that when I look at the request header 'Referer'. I only get the root address https://localhost:7004/. It does not send the rest of the URL.

Here is the request 'Referer' in migrated project, not hosted with ASP.NET Core

I can see from my research that 'Referer' probably isn't used like this much, because there is no info at all about this header.

Does anyone know if this could be me switching to Auth0, or is there is any change between .NET 5 and .NET 6 I should be aware of.

Or maybe just info about how I can control this.

I add the NSwagClients like this (using the newest NSwag versions):

string webApiBaseAddress = builder.Configuration["webApiBaseAddress"] ?? string.Empty;

builder.Services.AddTransient<AuthorizationMessageHandler>(sp =>
{
    // Get required services from DI.
    var provider = sp.GetRequiredService<IAccessTokenProvider>();
    var naviManager = sp.GetRequiredService<NavigationManager>();

    // Create a new "AuthorizationMessageHandler" instance,
    //    and return it after configuring it.
    var handler = new AuthorizationMessageHandler(provider, naviManager);
    handler.ConfigureHandler(authorizedUrls: new[] {
      // List up URLs which to be attached access token.
      naviManager.ToAbsoluteUri($"{webApiBaseAddress}/api/authorized/").AbsoluteUri
    });
    return handler;
});

builder.Services.AddHttpClient<ITeamClient, TeamClient>(client =>
    client.BaseAddress = new Uri(webApiBaseAddress)).AddHttpMessageHandler<AuthorizationMessageHandler>();

I figured it out after spending a lot of days on this.

The problem was that ASP.NET Core Hosted Blazor Webassembly calls the API with the same Origin, so the 'Referrer Policy': 'origin-when-cross-origin' did not restrict the 'Referer' header.

'origin-when-cross-origin' is the standard for 'Referrer Policy', and restricts the 'Referer' header for cross-origin calls.

But when I ran it with Blazor Webassembly and ASP.NET Core Web API each in their own project, they were localhost:7004 and localhost:7170, which are seen as same-site but not same-origin, so it was restricted to only show 'Origin' as the 'Referer' header.

I can't seem to find any way to make the API and Blazor be from the same 'Origin', so I have made my application somewhat less secure for now, by setting <meta name="referrer" content="no-referrer-when-downgrade"> in my index.html file in Blazor Webassembly.

My application does not send user sensitive information in the URL ever, and everything is using HTTPS, so it isn't really that much of a problem if the 'Referer' is read by an external source.

I will be looking at a better solution to tell my API from what Team the caller is trying to access content, to check if the caller also has the policy in the JWT to access it, but for now this will do.