Set referrerPolicy automatically for OpenStreetMap

[Firefishy]

OpenStreetMap.org's tile use policy requires a valid HTTP Referer, but sites often set a Referrer-Policy=no-referrer or Referrer-Policy=same-origin which stops the browser sending a HTTP Referer.

This change ensures that the tile fetches send a referer when fetching tiles from tile.openstreetmap.org.

Currently approximately 10% of tile.openstreetmap.org's tile traffic is from sites which are not sending a HTTP Referer.

Disclosure: I am part of the OpenStreetMap.org Operations Team who are responsible for technically enforcing the tile usage policy.

Fixes: #10156

[tomhughes]

Isn't the solution to add that option to the OSM layer in https://github.com/openstreetmap/leaflet-osm/? I don't think hard coding something based on the host here is reasonable...

[Firefishy]

Isn't the solution to add that option to the OSM layer in https://github.com/openstreetmap/leaflet-osm/? I don't think hard coding something based on the host here is reasonable...

I'll also PR the change there, but would be good to get this upstreamed directly. Alternative might be to improve the examples.

[jonkoops]

Starting to think we should be splitting out OSM specific logic out of TileLayer and into a dedicated OSMTileLayer since more logic for a specific provider is being added to something that should be a generic implementation. @Falke-Design @mourner WDYT?

Additionally, this is likely something we want to backport to 1.x?

[IvanSanchez]

@Firefishy I'm going over https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/referrerPolicy and https://w3c.github.io/webappsec-referrer-policy/#referrer-policy , and according to those, all browsers should be already using a default value of strict-origin-when-cross-origin. So for the default use case this change should do nothing; but it will override those cases where JS devs explicitly set up a different referrer policy. (And that last scenario is explicitly against OSMF's usage policy, and you'll do good in blocking those requests).

Or is there any scenario (or browser) in which Leaflet, using defaults, does not send referrer on the tile image requests??

I'd be more comfortable changing the default value at...

Leaflet/src/layer/tile/TileLayer.js

Line 87 in 0eee377

referrerPolicy: false

...to strict-origin-when-cross-origin (which should cover unruly user agents) and still letting JS devs change behaviour if they want.

Starting to think we should be splitting out OSM specific logic out of TileLayer and into a dedicated OSMTileLayer since more logic for a specific provider

@jonkoops I stand by what I said at #9228 (comment) . If we had four different tile providers with four different hacks for each one, I'd be in favour of refactoring; but with only OSM I'd leave it be.

[Firefishy]

@Firefishy I'm going over https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/referrerPolicy and https://w3c.github.io/webappsec-referrer-policy/#referrer-policy , and according to those, all browsers should be already using a default value of strict-origin-when-cross-origin. So for the default use case this change should do nothing; but it will override those cases where JS devs explicitly set up a different referrer policy. (And that last scenario is explicitly against OSMF's usage policy, and you'll do good in blocking those requests).

Or is there any scenario (or browser) in which Leaflet, using defaults, does not send referrer on the tile image requests??

strict-origin-when-cross-origin is indeed the modern browser default and a referer is sent, but it appear approximately 10% of tile.openstreetmap.org user base (see Client Error Responses by Status) set a stricter Referrer-Policy=no-referrer or Referrer-Policy=same-origin (or similar). For a ~6 hour window late Sunday we (OpenStreetMap) enforced a Referer requirement, since reverted.

Update: To clarify, I suspect most of the 10% are setting the Referrer-Policy globally and not specific to Leaflet. Example site doing so via <meta name="referrer" content="no-referrer">.

[jonkoops]

If we had four different tile providers with four different hacks for each one, I'd be in favour of refactoring; but with only OSM I'd leave it be.

That is fair, let's leave it as-is.

[Falke-Design]

I don’t think it’s a good idea to force the referrer header. I suggest closing this PR

[Firefishy]

@Falke-Design The alternative acceptable? - Updating all leaflet examples that use OpenStreetMap to include explicitly setting referrerPolicy?

[Falke-Design]

@Firefishy what if OSM doesn't enable this rule? 😉 How are other libs like OpenLayers are handling this?

The fact is that Leaflet is not only used for providing OSM tiles, and adding more and more custom OSM-specific code should not be our goal.

[Firefishy]

I am part of the OpenStreetMap sysadmin team. We are going to enforce the referer requirement per our https://operations.osmfoundation.org/policies/tiles/

Yes, there other libraries, but leaflet is the most common when using OpenStreetMap tiles.

[Falke-Design]

I am part of the OpenStreetMap sysadmin team. We are going to enforce the referer requirement per our https://operations.osmfoundation.org/policies/tiles/

That was what I meant, just don't enforce it 😉 Just joking, but I'm still not sure if it should be really in the core library.

@mourner thoughts?

[Firefishy]

That was what I meant, just don't enforce it 😉 Just joking, but I'm still not sure if it should be really in the core library.

After excluding app specific UAs, ~ 10% / ~ 126,000 GB/month of our tile.openstreetmap.org traffic is unidentified "anonymous" traffic where the referer is missing. Month by month the figure grows. It isn't sustainable.

[jonkoops]

I am not against landing this in Leaflet per-se, especially if it will be a future requirement for using OSM on the web. Do note that Leaflet has a long history, so there are likely a lot of applications out there that will never upgrade to a version that will include these changes.

@Firefishy one thing I am confused about, is that it seems the default value from browsers is already strict-origin-when-cross-origin (see MDN).

[Firefishy]

@Firefishy one thing I am confused about, is that it seems the default value from browsers is already strict-origin-when-cross-origin (see MDN).

strict-origin-when-cross-origin is indeed the default, but during our Sunday 6 hour experiment we found a large number of websites had set referrer-policy=no-referrer or referrer-policy=same-origin or similar which changes the behaviour. Most appear to have been unaware of the impact. Examples: openstreetmap/tile-attribution#160 openstreetmap/tile-attribution#159 openstreetmap/tile-attribution#150 openstreetmap/tile-attribution#162 openstreetmap/tile-attribution#152 openstreetmap/tile-attribution#153 openstreetmap/tile-attribution#148

[jonkoops]

Got it (sorry I skimmed over the comments above too fast), in that case, this all LGTM logic wise. If you could address the review comment I had about code duplication in the review, I have no objection against merging this.

[Firefishy]

@jonkoops Refactored as requested to remove duplication. Hopefully suitable now.

[Firefishy]

How are other libs like OpenLayers are handling this?

openlayers/openlayers#17089

[jonkoops]

We should probably update the documentation of this field to state that it will default to strict-origin-when-cross-origin for OSM hosts, and that it cannot be disabled for those.

[Firefishy]

The automatic option value can be disabled by setting the option referrerpolicy.

[jonkoops]

I mean to say, currently the following documentation provides no information to the user that for OSM URLs the default behavior will be different when defaulting to false:

https://github.com/Firefishy/Leaflet/blob/0eee3776d3a6929aad71c2fa112bc4a935b0950c/src/layer/tile/TileLayer.js#L81-L87

[Firefishy]

I'm happy to PR the addition. How about?

"OpenStreetMap special case: If the tile URL host is tile.openstreetmap.org and referrerPolicy is unset, Leaflet automatically applies "strict-origin-when-cross-origin" so that a valid Referer is sent, complying with the OpenStreetMap Tile Usage Policy. Set referrerPolicy explicitly if you need a different value."

[Firefishy]

Or a shorter version:
"Note: When the tile URL host is tile.openstreetmap.org and this option is not explicitly set, Leaflet will default referrerPolicy to "strict-origin-when-cross-origin" to ensure a valid Referer is sent in line with the OpenStreetMap Tile Usage Policy."

[Firefishy]

Or shortest:
"If using tile.openstreetmap.org and unset, this defaults to strict-origin-when-cross-origin to comply with the OSM Tile Usage Policy."

[simon04]

I like the "shorter version" best. :)

[IvanSanchez]

@Firefishy By any chance, do you have a drill-down of tile requests with no referrer set, split by HTTP vs HTTPS?

I'm wondering if HTTPS sites are using HTTP tiles, and the downgrade is what's making the browser not set the referrer header.

[Firefishy]

@Firefishy By any chance, do you have a drill-down of tile requests with no referrer set, split by HTTP vs HTTPS?

I'm wondering if HTTPS sites are using HTTP tiles, and the downgrade is what's making the browser not set the referrer header.

Unfortunately I don't have those details to hand. Our CDN does the redirects.

I don't think setting an "unsecure" Referrer Policy would be a good idea.

[IvanSanchez]

I don't think setting an "unsecure" Referrer Policy would be a good idea.

@Firefishy I'm not thinking about that.

I'm thinking that, if the user is doing L.TileLayer('http://tile.osm.org/....'), the Leaflet code could (should?) automatically change that into https://tile.osm.org/.... (note http vs https).

---

Bit of extra context: I've done a quick test in here (Linux+Firefox 141, "HTTPS only" mode off), in the https://leafletjs.com/edit . If I set the tile url to http://tile.osm.org, then the browser somehow upgrades the tile requests to HTTPS, but does not send the Referrer header.

And, what's more, setting the referrerPolicy to strict-origin-when-cross-origin has no effect.

Seems that there's a weird exception to the cross-origin referrer policy when there's automatic HTTP→HTTPS upgrades going on.

[IvanSanchez]

Currently approximately 10% of tile.openstreetmap.org's tile traffic is from sites which are not sending a HTTP Referer.

I can not believe that ~10% of Leaflet deployments out there are messing with the referrerPolicy option of tilelayers. I can, however, believe that ~10% of Leaflet out there is using http://tile.osm.org instead of https://tile.osm.org.

See 3050929

[fabricesaitec-cell]

I actually using leaflet with OSM and have error message 'Access blocked refere is required by tile usage policy of OpenStreetMap's volunteer-run servers osm.wiki/Blocked' since last week (20/03/2026)

I did the modifications on the html source code, I also tried to add the option 'referrerPolicy' in TileLayer, but the problem still remain the same.

To reproduce the problem, I use the code of the example showed on the leaflet website https://leafletjs.com/examples/custom-icons/example-one-icon.html where I did the following modifications:

=> Added line '<meta name="referrer" content="strict-origin-when-cross-origin>'
=> Modified line 'L.tileLayer('https://tile.openstreetmap.org/{z}/{x}/{y}.png', {
attribution: '© OpenStreetMap contributors', referrerPolicy: 'strict-origin-when-cross-origin'
}).addTo(map);'

When I load the HTML file which contain the modified source code, with a navigator (Edge, Chrome...), Il still have the error message when I zoom on the map.

What can I do to avoid this error message ? Thanks

example_osm_leaflet.htm

[matthieumarrast]

Some anti-trackers (like bitdefender Anti-tracker) remove the Referer header from the tile request to tile.openstreetmap.org, so it leads to this annoying "403r - Access blocked - Referer is required" error.

[christopher-reineborn-pini]

I actually using leaflet with OSM and have error message 'Access blocked refere is required by tile usage policy of OpenStreetMap's volunteer-run servers osm.wiki/Blocked' since last week (20/03/2026)

I did the modifications on the html source code, I also tried to add the option 'referrerPolicy' in TileLayer, but the problem still remain the same.

To reproduce the problem, I use the code of the example showed on the leaflet website https://leafletjs.com/examples/custom-icons/example-one-icon.html where I did the following modifications:

=> Added line '<meta name="referrer" content="strict-origin-when-cross-origin>' => Modified line 'L.tileLayer('https://tile.openstreetmap.org/{z}/{x}/{y}.png', { attribution: '© OpenStreetMap contributors', referrerPolicy: 'strict-origin-when-cross-origin' }).addTo(map);'

When I load the HTML file which contain the modified source code, with a navigator (Edge, Chrome...), Il still have the error message when I zoom on the map.

What can I do to avoid this error message ? Thanks

example_osm_leaflet.htm

This may not help you, but it could possibly help others. But I'm developer of a React app which we serve through as a webapp and Electron. For the webversion it was enough the add <meta name="referrer" content="origin"> to index.html meanwhile for the Electron version I had to exclusively add the referer in index.ts under app.whenReady for OSM.

session.defaultSession.webRequest.onBeforeSendHeaders(
      (details, callback) => {
        if (details.url.includes("tile.openstreetmap.org")) {
          details.requestHeaders["Referer"] = "https://www.website.com/";
        }
        callback({ requestHeaders: details.requestHeaders });
      }
    );

[jslippy]

This may not help you, but it could possibly help others. But I'm developer of a React app which we serve through as a webapp and Electron. For the webversion it was enough the add <meta name="referrer" content="origin"> to index.html meanwhile for the Electron version I had to exclusively add the referer in index.ts under app.whenReady for OSM.

session.defaultSession.webRequest.onBeforeSendHeaders(
      (details, callback) => {
        if (details.url.includes("tile.openstreetmap.org")) {
          details.requestHeaders["Referer"] = "https://www.website.com/";
        }
        callback({ requestHeaders: details.requestHeaders });
      }
    );

I'm also a developer of an Electron app using OSM tiles in Leaflet. Some of our users have reported tiles occasionally being blocked with the 403r message stating a Referer is required. Although our app already includes a Referrer-Policy of strict-origin-when-cross-origin it does not include a Referer header because it is exclusively a "native" app and not served via the Web. As far as I can tell we are fully complying with the OSM tile usage policy, which states "Native apps usually do not have a referer, this is ok." Our User-Agent does include the name and version of our app, along with the other info Electron includes by default (platform, renderer, Chrome version, Electron version, Safari version). It does not include contact info, which is listed as "optional" in the tile policy. @Firefishy or @pnorman It sounds like this is happening to other Electron apps besides ours. Is it possible your enforcement of the policy is more strict than the policy itself? Maybe the Chrome tokens in the user agent make these apps look like web apps and the Electron and app-specific version tokens are being missed?

[pnorman]

This issue is just about Leaflet's default referrerPolicy. If you've got other questions as to why you're getting blocked, you can email operations at osmfoundation.org with technical details including headers being sent.

[PizzaProgram]

An interesting Node-RED case study about this problem, in Wordmap module:

https://discourse.nodered.org/t/worldmap-access-blocked-error-r403/100759
Summary: It seemed 403r error has to do with Win7 vs Win10+, but actually it was uBlock origin plugin causing it.

[Falke-Design]

The Brave Browser causes troubles too

[mourner]

Superceded by #9897