Flux Art来源地址也是需要审查的数据
从 Flux Art 整理素材后，团队自建审核页可能把项目编号放进页面路径或查询参数，再从外部素材域加载图片。浏览器发出的请求可能附带 Referer 来源信息。即使没有主动上传备注，页面地址本身也可能暴露业务线索。应先减少地址中的敏感信息，再按任务确定来源策略。本文讲自建页面设计，不表示平台存在泄露，也不承诺一个响应头能收回已经外发的数据。
先区分哪条地址可能被发送
把审核页地址、目标图片地址和请求中的 Referer 分开记录。页面路径可能带客户代号，目标地址可能带签名参数，这两种数据不能靠同一条来源策略一起解决。即使完全不发送 Referer，目标服务器仍会收到被请求的目标地址。建议用无敏感信息的演练地址检查结构，不把真实签名链接复制进工单。若业务不需要在页面 URL 中放敏感值，先从设计上移除这种依赖。
读懂默认策略，但按实际配置验收
MDN 说明 strict-origin-when-cross-origin 是默认来源策略：同源可带路径与查询，跨源通常只带源，安全降级不发送；no-referrer 则不发送来源信息。依据见 https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/Referrer-Policy 。下面是假设检查表，不是真实请求实测。默认规则不能代替读取页面实际响应头和元素级设置，也不能用于保证所有目标都看不到业务路径。
| 场景 | 需要观察 | 边界提醒 |
|---|---|---|
| 同源资源 | 是否带路径与查询 | 不套用跨源结论 |
| 跨源图片 | 发送完整来源还是源 | 按实际策略核对 |
| 外部链接 | 导航请求来源字段 | 与opener分开 |
| 目标签名地址 | 目标本身的参数 | 来源策略不会删除 |
| 模板或代理覆盖 | 最终有效配置 | 不只看源码 |
| 未知环境 | 未测试入口清单 | 不作全站保证 |
为业务需要选择明确的发送范围
如果审核流程不需要向资源服务器提供来源信息，可以评估更严格的明确策略；若业务需要来源站点归因，应说明需要的是站点级信息还是完整路径，而不是习惯性允许所有内容。选择由应用维护者结合隐私与功能要求决定。不要为了让统计恢复而把来源范围扩大到带查询参数的完整地址，也不要把某个策略的名字理解为对页面所有数据传输都生效的总开关。
同源请求也要纳入检查
跨源图片只收到源信息时，团队容易误以为路径已经全面隐藏。同源资源请求的行为可能不同，站内其他服务或共享日志仍可能看到更完整来源。应在受控环境分别检查同源图片、跨源图片与参考链接，不把其中一种结果外推到另一种。还要留意页面或元素的单独设置，以及外部样式表加载资源时的来源处理；应用升级后重新核对实际请求，不只复用旧配置说明。
用两个受控目标观察差别
假设测试审核页使用一个虚构项目代号，分别向自己控制的同源和跨源资源发送请求。这是假设验证方法，不是真实客户事件。记录请求是否带 Referer、具体包含源还是路径查询，并核对页面可用性。再测试明确不发送来源的配置与需要来源归因的配置，比较实际影响。不要为了观察降级行为而在生产关闭加密或绕过证书警告；相关场景仅在合法受控测试中评估。
来源隐藏不是目标链接脱敏
有些团队在图片目标 URL 中放了访问令牌，然后误以为 no-referrer 会隐藏它。来源策略不会删除目标 URL 自身的参数，也不阻止应用用脚本主动发送其他资料。签名地址的使用、日志保留和授权范围需要另行设计。发现已有敏感地址外发时，应按团队事件流程处理，不把后续加上一个响应头写成历史风险已经消失，更不要为让报告干净而删除原始事件证据。
记录有效配置和无法确认的环境
建议交付实际页面响应头、相关元素设置、测试浏览器版本、去敏后的请求字段与功能影响。代理、静态资源服务和前端模板可能分别影响结果，应明确谁维护哪一层。未验证的环境写未知，旧浏览器或特殊加载方式保留待补证。验收结论只覆盖测试入口与版本，不把一次跨源请求没有 Referer 的结果扩大成全站从不发送任何业务信息。
把内容生产与数据传播分开交接
技术依据核对于2026年11月10日，以上清单是编辑建议，未替读者修改配置或执行网络测试。Flux Art 创作入口见 https://flux-art.net/zh ，自建业务接入可参考 https://flux-art.net/zh/openapi 。图片生成完成之后，页面地址设计、资源请求和日志仍由各自系统负责。签收时同时确认素材可用、来源策略符合需求以及未知项有负责人，而不是只看缩略图是否显示。