2026 年 11 月 13 日，开源数据工具 Datasette 创始人 Simon Willison 发布了基础插件 datasette-leaflet 0.3 版本。这次更新只做了一件小事，把发往外部服务器的地图瓦片请求策略改成了 strict-origin-when-cross-origin。就是这几行代码的调整，终结了困扰 Datasette 地图插件生态半年之久的 OpenStreetMap 瓦片报错难题，在不暴露用户数据查询路径的前提下，完成了对公共开源基础设施合规要求的请求级妥协。

事情要追溯到 2026 年 5 月 5 日。当时 Simon Willison 在维护全球发电厂演示项目（global power plants demo）时发现，页面上的地图全部变成了红色的错误瓦片，提示 Access blocked 或 Referer is required。这种报错并非代码写错，而是两个开源项目在浏览器底层安全机制上撞了车。

为什么一张地图瓦片会引发隐私与合规的对撞

要看懂这次更新的价值，得先明白 Datasette 和 OpenStreetMap 各自在防什么。

隐藏来源信息导致地图瓦片请求被服务器直接拦截(示意图)
隐藏来源信息导致地图瓦片请求被服务器直接拦截(示意图)

Datasette 是一个把数据库直接变成交互式网页的工具，它的 URL 路径和查询字符串里，往往直接写着数据库名、表名、筛选条件甚至完整的 SQL 查询语句。如果用户在数据页面点击了一个外部链接，或者页面加载了第三方图片，浏览器默认会把完整 URL 放在 HTTP 请求的 Referer 标头里发给对方。为了防止敏感的查询逻辑和业务参数顺着网络请求泄露，Datasette 默认在表格页面加上了极其严苛的 Referrer-Policy: no-referrer 标头，一刀切地抹掉了所有外发请求的来源信息。

但这直接触碰了 OpenStreetMap 的红线。作为靠捐赠和志愿者维持的免费公益基础设施，OpenStreetMap 的托管瓦片服务器每天要承接全球海量的地图加载请求。为了追踪异常流量来源、联系滥用资源的开发者并防止恶意爬虫盗链，OpenStreetMap 制定了一条完全合情合理的规矩，所有发往其公共瓦片服务器的请求必须携带合法的 Referer 标头。当一刀切抹掉来源的 Datasette 遇上必须查验来源的 OpenStreetMap，结果就是瓦片请求被直接拒之门外。

隐私防御与公共合规的底层冲突 Datasette 默认隐私防御 URL 含表名、筛选条件与 SQL 策略：no-referrer 外发请求抹除全部来源信息 后果：触发 OSM Access blocked datasette-leaflet 0.3 单点豁免 调用 Leaflet 1.8.0+ 图层级配置 策略：strict-origin-when-cross-origin 仅向瓦片服务商发送主域名 收益：合规加载瓦片且藏匿 SQL

从全站妥协到请求级豁免的架构演进

在 0.3 版本发布前，开发者如果要在 Datasette 里正常显示地图，通常只能采取一种粗放的补救办法，安装 datasette-referrer-policy 插件，把整个网站所有页面的 HTTP 响应标头统一改写为 strict-origin-when-cross-origin。

在全局封闭的防御策略下为地图瓦片开设单点豁免
在全局封闭的防御策略下为地图瓦片开设单点豁免

这种改法虽然能让地图重新加载出来，但作用范围过大。它相当于为了给地图瓦片放行，把整个数据站点所有外部资源请求的防御等级都降了一档。现代 Web 安全讲究最小权限原则，为了一张地图去修改全站的 HTTP 响应头，在工程设计上并不优雅。

datasette-leaflet 作为底层依赖库，负责把打包好的 Leaflet JavaScript 库注入页面，供上层的地图插件调用。早在 Leaflet 1.8.0 版本中，官方就为 tileLayer 引入了 referrerPolicy 选项，允许开发者针对单张瓦片图像的 DOM 请求，单独覆盖整个网页文档的默认策略。

Simon Willison 这次正是利用了这一特性，在 0.3 版本中直接把瓦片请求本身的策略设为 strict-origin-when-cross-origin。这样一来，Datasette 页面依然保持着严密的 no-referrer 全站防御，唯独在向 OpenStreetMap 请求地图图片时，浏览器会乖乖递上站点主域名（Host），同时把域名后面那串敏感的数据库表名和 SQL 路径截断留在本地。

好的安全工程从不一刀切，而是在封闭的全局默认下做颗粒度极细的单点放行。

为了让上层插件和开发者拥有更高的控制权，0.3 版本还新增了名为 tile_referrer_policy 的插件配置项，并在前端暴露为 datasette.leaflet.TILE_REFERRER_POLICY 全局变量。如果开发者在具体的业务代码里为单个瓦片图层单独指定了 referrerPolicy 选项，其优先级会高于这个全局默认设置。对于生态内的插件维护者和普通用户来说，现在不需要再折腾全站安全标头，只需升级底层依赖，就能在保住查询隐私的同时恢复地图显示。

  • 结论.其他同样默认采用强隐私标头（no-referrer）的现代 Web 框架或 BI 报表工具，在集成第三方公共组件时，完全可以借鉴这种全局严守、组件级按需降级的前端加载模式。
从发现报错到请求级修复的演进时间线 Leaflet 1.8.0 底层引入 tileLayer referrerPolicy 选项 2026年5月5日 发电厂 Demo 瓦片被拒 早期靠全站插件妥协 2026年11月13日 发布 0.3 版本 实现瓦片请求级精准放行

隐去 URL 路径之后，还有哪些隐私正在裸奔

把策略改成只发主域名不发路径，确实挡住了 SQL 语句外泄，但这并不意味着在内部高敏数据系统里可以直接放心大胆地调用公共地图服务。很多开发者容易忽略一个底层通信事实，只要你的浏览器直接向第三方瓦片服务器发起了网络请求，你就依然在让渡关键的行为隐私。

瓦片网格坐标与访问者IP仍会暴露所查看的敏感区域
瓦片网格坐标与访问者IP仍会暴露所查看的敏感区域

修改 Referrer-Policy 只能藏住用户在哪个具体数据表页面的上下文隐私，却藏不住用户在看地图哪里的空间行为隐私。当浏览器向 tile.openstreetmap.org 请求图片时，访问者的真实 IP 地址会直接暴露给对方服务器。同时，标准瓦片 URL 采用的是 {z}/{x}/{y} 网格坐标结构，这串数字直接对应着地图的缩放级别（Zoom）和具体的经纬度网格。

这就意味着，即便第三方瓦片服务商看不到你的 SQL 查询参数，它依然能把访问者 IP、数据站点主域名以及用户正在放大查看的具体地理区域这三项信息精准关联起来。如果一家商业机构或调查记者正在用 Datasette 分析某处未公开的矿产分布、供应链仓储或敏感设施，单凭瓦片请求里的坐标网格和缩放动作，外部基础设施维护者就能倒推出调查者正在重点审视哪几平方公里的土地。

  • 风险.在涉及商业机密或敏感地理围栏的内网数据分析场景中，仅靠 strict-origin-when-cross-origin 无法阻断通过 {z}/{x}/{y} 瓦片坐标与 IP 进行的地理位置推断，真正敏感的业务必须切断第三方外部调用，改为自建私有瓦片服务器。