OpenStreetMap tiles show a 403 Access blocked overlay in the block editor

Summary

The OpenStreetMap-based Maps block can display 403 blocked-response tiles over the map in the WordPress block editor. The editor is expected to load usable map tiles so existing locations and markers can be edited. Instead, the blocked tiles obscure the map and prevent normal editor interaction, while the reported published map remains visible.

Customer context

• Product / area: Otter Blocks, OpenStreetMap/Leaflet Maps block editor
• Version: Not provided; the integration remains present in inspected tag v3.2.5
• Environment: WordPress block editor; Windows 10; Chrome 153; desktop
• Integration / third party: OpenStreetMap raster tile service through bundled Leaflet 1.8.0
• Reported error / symptom: 403 Forbidden banner over the editor map; a separate September 2026 support report documented an OSM 403 Access blocked tile in Chrome
• Impact: Existing OSM maps cannot be used normally in editing mode, although the published map was reported as still visible

Reproduction notes

Reported workflow:

1. Open a page containing an existing Otter OpenStreetMap Maps block in the WordPress editor.
2. Observe a 403 Forbidden banner over the map.
3. Attempt to interact with or edit the map; the overlay prevents normal use.
4. View the published page; the map is reported as still visible.

The current customer environment was not reproduced locally. A separate support conversation from the previous day included a screenshot of an OSM 403 Access blocked tile in the editor, providing independent corroboration. Exact Otter version, tile request headers, response body, and site referrer policy are missing.

Diagnosis

Conclusion

Otter's current OSM integration can issue tile requests that do not meet the tile service's now-enforced contract. The source uses the legacy a/b/c host pattern rather than the provider's required canonical URL and does not declare a tile referrer policy. Otter bundles Leaflet 1.8.0, while Leaflet only added a strict-origin-when-cross-origin TileLayer default in May 2026 specifically for OSM 403 blocked tiles. The provider's policy requires the exact canonical URL and a valid web Referer. This source mismatch, combined with two independent recent reports, confirms a product integration defect. The precise request-header or host rejection in this customer's editor was not captured.

Where this likely occurs

• Editor surface: src/blocks/blocks/leaflet-map/edit.js — Edit::createMap() lines 202–260 initializes the iframe-owned Leaflet map and creates the tile layer with https://{s}.tile.openstreetmap.org/..., explicit a/b/c subdomains, and no referrerPolicy option.
• Editor context: src/blocks/blocks/leaflet-map/edit.js — Edit::getLeaflet() lines 84–92 and the initialization effect at lines 337–353 load Leaflet into the Gutenberg canvas iframe, where request/referrer behavior can differ from the public page.
• Front-end surface: src/blocks/frontend/leaflet-map/index.js — createLeafletMap() lines 57–95 uses the same legacy tile host pattern and lacks an explicit tile referrer policy.
• Bundled dependency: assets/leaflet/leaflet.js — preserved header lines 1–3 identifies Leaflet 1.8.0; the minified TileLayer implementation is on line 5. This version predates Leaflet PR #9897, merged as fecde4eda9ac5123faf35cacf50ee6565b0240f0 on 2026-05-11.
• History: the legacy HTTPS subdomain URL dates to commits d411f9ab and 72d29300 from November 2021. No inspected Otter commit added a map referrer-policy safeguard. Current checkout/tag is v3.2.5.

Engineering notes

The OSM policy currently specifies exactly https://tile.openstreetmap.org/{z}/{x}/{y}.png, warns that other subdomains may be withdrawn, and requires a valid Referer for web requests. Modern browser defaults ordinarily send one, but a site-wide restrictive referrer policy, privacy tooling, or iframe context can suppress it. Leaflet's upstream safeguard was motivated by OSM enforcement affecting such environments. Otter's editor and front end use the same tile configuration, so the reported editor-only result may involve editor request context or previously cached public tiles; that asymmetry is not yet isolated. No Otter code generates a 403 banner itself: the visible banner is consistent with an image response returned for rejected tile requests.

Test coverage status

src/blocks/test/e2e/blocks/leaflet-map.spec.js covers editor initialization, markers, persistence, published rendering, gestures, popups, tooltips, and zoom behavior. Its Maps (Leaflet) block setup at lines 39–47 intercepts every *.tile.openstreetmap.org request and returns a synthetic PNG, so the suite does not exercise provider status codes, canonical-host compatibility, referrer headers, iframe rejection, or blocked-tile rendering. No relevant unit coverage was found during inspection.

What to verify or explore next

• Reproduction in the Gutenberg editor with a real OSM tile request, recording request URL, Referer, response status, and blocked-tile text.
• Comparison of the same map's editor and anonymous front-end requests with browser cache disabled.
• Compatibility checks under default, no-referrer, and same-origin site response policies.
• Real-provider checks for the canonical host and legacy a/b/c hosts in supported browsers.
• The Maps Playwright suite at src/blocks/test/e2e/blocks/leaflet-map.spec.js, including a controlled 403 tile response and editor interaction assertions.

Unknowns / follow-up

• The customer's Otter and WordPress versions were not provided.
• The current thread contains no Network-panel capture, response body, screenshot, or response headers, so the exact rejection category is unknown.
• Browser extensions, security headers, caching, and request volume on the affected site are unknown.

Confidence

Confidence: 91/100

Current Otter source uses an OSM tile integration that does not satisfy the provider's enforced request contract, and two independent September 2026 support reports show the resulting blocked tiles. The bundled Leaflet 1.8.0 predates its referrer-policy safeguard, real provider responses are mocked in Otter's tests, and no open Otter issue tracks this behavior.

---

Source: HelpScout #3451061064
Generated by bug-report-triage (ID: bug-report-triage_6aa88a9e4d8033.26584307)