Error 403 referer missing when missing on local files when using Firefox but not Chromium

[fooltech]

For many years I have used Firefox on local files with tiles I understand because of bot attacks that openstreetmap now requires the referer policy

1)If I use the Chromium browser I do not get this error and cannot understand why if referer is required on all browsers this should be the case.

2)Is there a fix or modification in Firefox such that it works in a similar fashion to Chromium, Firefox being my default browser, I suspect it maybe down to settings being different between the two.

Grateful for any suggestions.

phil

[Mateusz_Konieczny]

are you using any referrer-stripping addons in Firefox?

are you using updated Firefox?

is it still happening when you upgrade browser and disable extensions?

(my Firefox works fine)

[fooltech]

Firefox ver 155.0.1
Only Extension Ublock Origin which is now off
Enhanced tracking is set at custom with an exception for
hhtps://www.openstreetmap.org
PC is raspberry pi5 with latest Operating system updated Debian13 (trixie)
Thanks for responding
phil

[Spiekerooger]

Will not work if you have a local file on your raspberry where e.g. you use leaflet or the like to get tiles by osm. Why? Because with a local file, the referrer will not be transferred in FF and so you will not adhere to the tile usage policy.

[citrula]

I tested it in Chrome and FF and confirmed that the tiles are only blocked in Firefox, like OP stated.

[fooltech]

So that would appear to suggest Firefox is doing something others are
not I will now try the Firefox community to see if anyone else is having
this issue and why.

Thanks for your replies
phil

[whb]

@Spiekerooger

Why? Because with a local file, the referrer will not be transferred in FF

A test with a local HTML file showed that while Chrome and Edge load the tiles correctly, Firefox displays the 403r error tiles. However, according to the Developer Tools, no referrer is sent in the request header by any of the three browsers.
So why does it work without a referrer in the other two browsers, but not in Firefox?

[trial]

A cache issue maybe?

[whb]

I can rule out the browser cache. I tested it in a completely new VM where openstreetmap.org had never been accessed, only the local HTML file.

[trial]

And you start chromium, not chromium --allow-file-access-from-files I guess.

[whb]

I started Chrome without parameters. Actually, it was the installer that opened it automatically after the installation.

I just broke the problem down to a minimum. It seems like only the Firefox user agent gets blocked when no referrer is sent.

Chrome UA without referrer works:

curl -X GET "https://tile.openstreetmap.org/10/546/353.png" \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/153.0.0.0 Safari/537.36" \
  -H "Accept: image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8" \
  -o tile_chrome.png

Firefox UA without referrer does not work:

curl -X GET "https://tile.openstreetmap.org/10/546/353.png" \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:155.0) Gecko/20100101 Firefox/155.0" \
  -H "Accept: image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8" \
  -o tile_ff_no_referrer.png

Firefox UA with referrer works:

curl -X GET "https://tile.openstreetmap.org/10/546/353.png" \
  -H "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:155.0) Gecko/20100101 Firefox/155.0" \
  -H "Accept: image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8" \
  -H "Referer: https://www.openstreetmap.org/" \
  -o tile_ff.png

[fooltech]

I can confirm this I clear the browser cache and history every time
Firefox closes.
phil

[whb]

By the way, in Firefox you can use “Responsive Design Mode” (Ctrl + Shift + M) to temporarily change the user agent for the current tab to Chrome, for example. Then the tiles will work for the local HTML file as well.

Responsive Design Mode — Firefox Source Docs documentation

[fooltech]

Thanks to Whb

Work round for Firefox not opening local files with OpenStreetMap tiles.

The issue is the Firefox “User Agent” not allowing Referer Policy to
work and a solution is to change it for the Chrome User Agent
This is only a partial fix because although the map is visible depending
on Scrolling In/Out the error message can appear and eventually the map
disappear.
Implementation Steps

1. CTRL+SHIFT+M takes you to the Responsive Design Mode
   Alternatively goto More Tools, Responsive Design Mode
   Which Displays another MenuBar
2. Goto Settings (Gear Cog between Camera and Close icons right hand end
   menubar)
   Select Show User Agent
3. Click Up/Down Arrows next to UA Custom User Agent Box
4. Select Chrome

You will then have to sort your screen size at left hand end of menubar.
This is really all about accommodating mobile phones.
phil

[TomH (Tom Hughes)]

No the solution is not to lie about your browser’s identity - that is the sort of thing that will get you blocked.

The solution is to contact operations for assistance.

[fooltech]

Thanks this is not a lie but a valid option within Firefox ver 155
Regarding contacting Mozilla all evidence currently is that they know
about the issue but are not working on it.
phil

[GeoDeskTeam]

I’m in touch with @firefishy at OSMF Ops. The same issue currently affects the maps produced by the various GeoDesk tools (which are local HTML files with Leaflet content). *

The core issue is that browsers don’t send Referrer headers for local files (opened via file:// instead of https://), so these files cannot comply with the Referrer rule of the Tile Usage Policy.

@firefishy confirmed that sending an X-Requested-With header in lieu of Referrer would comply with the policy (Applications that download tiles via a direct HTTP request already do so). However, usage in a browser requires a preflight request for each tile (X-headers can present a security risk, so the browser has to ask the server if it’s ok to send them for each URL). This is inefficient, since the browser now has to send two requests for each tile that isn’t already cached locally (Also somewhat counterproductive given that the Tile Usage Policy aims to reduce unnecessary load).

The other problem is that currently the OSM tile servers also apply the “no Referrer, no service” rule to the preflight requests themselves, so the browser’s request to send an X-Requested-With header is rejected outright, and subsequent tile requests fail.

An alternative I suggested is to allow tile consumers to append an app ID to the tile URLs as a request parameter (i.e. an “API token lite”). So instead of https://tile.openstreetmap.org/{z}/{x}/{y}.png, you would use https://tile.openstreetmap.org/{z}/{x}/{y}.png?app-id=MyMapApplication as the tile server URL.

I’m not a networking expert, so others may have better ideas.

---

*) For GeoDesk, you can work around this issue by specifying an alternative tile server (one that doesn’t require Referrer headers or a commercial operator with API tokens – e.g. Thunderforest, which has a generous free tier)

[trial]

Thanks for the details.

API tokens may be better than app-id, but it’s up to OSMF Ops.

It doesn’t explain why a “local” request from apparently Chromium is OK and a “local” request from apparently Firefox is not OK.

Using --verbose I see that the first request is served by server: Varnish for Chromium but server: Apache for Firefox with standard UA.

@firefishy, I’m not sure if the different servers are supposed to have a different behavior.

Main differences are:

Key	Chromium	Firefox
access-control-allow-headers	X-Requested-With	*
server	Apache	Varnish
strict-transport-security		max-age=31536000; includeSubDomains; preload
x-blocked		Access denied. See Tile Usage Policy

[GeoDeskTeam]

I believe that requiring API keys has been previously discussed (I can’t find the thread, it may have been on the old mailing list).

API keys come with their downsides, mostly in the form of administrative overhead.

That’s interesting that requests from different types of browsers are appear to be handled by different tile servers. Maybe they have different policy settings?

I can confirm that tiles load normally without Referrer on Chrome (with browser cache cleared), but are blocked (403r) in Firefox.

[TomH (Tom Hughes)]

There is absolutely no truth to the idea that different servers server different browsers. All requests are handled by the same CDN and the only requests which are sent to a specific set of backend servers are those from qgis.

The CDN does however have a lot of rules to try and block inauthentic access and they may sometimes behave differently for different browsers.