网关无法处理localStorage中的JSON数据，因其仅存在于浏览器端，不随HTTP请求自动发送；防护必须在前端读取、存储或渲染环节通过DOMPurify等工具净化，网关仅能对主动提交的请求数据做有限过滤。
直接在网关层对本地存储的 JSON 数据做 XSS 过滤，这条路走不通——因为网关（如 Spring Cloud Gateway、Nginx、Kong）本身不解析或操作浏览器 localStorage 中的数据。localStorage 是纯前端运行时环境下的 API，服务端网关根本无法访问、读取或修改它。
为什么网关无法处理 localStorage 中的 JSON
localStorage 属于浏览器上下文，数据仅存在于用户设备内存中，不会随 HTTP 请求自动发送到后端。除非你主动把 JSON 内容通过请求体（如 POST /api/submit）或请求头（如 X-Data）发给服务端，否则网关连“看到”它的机会都没有。
常见误解是以为“网关拦截所有流量，就能拦住所有 XSS”。但 XSS 风险若发生在前端渲染阶段（比如用 v-html 或 innerHTML 直接插入 localStorage 读出的内容），整个过程完全不经过网关。
真正可行的防护路径：分层拦截 + 前端净化
要让“从 localStorage 读出的 JSON 不触发 XSS”，关键不在网关，而在前端读取和使用环节。以下是实际可落地的组合策略：
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
立即学习“前端免费学习笔记（深入）”；
-
读取时净化：封装统一的
safeGetFromStorage(key)方法，在 JSON.parse 后立即对所有字符串字段递归清洗。例如用 DOMPurify（轻量白名单过滤器）处理可能含 HTML 的字段：const cleanHtml = DOMPurify.sanitize(dirtyString, {ALLOWED_TAGS: ['b','i','p'], ALLOWED_ATTR: ['class']}); -
渲染时约束：禁止直接
el.innerHTML = data.content。改用安全方式：
– 纯文本内容 →el.textContent = data.content
– 必须渲染富文本 → 仅通过DOMPurify.sanitize()后再赋值innerHTML -
存储前就过滤（推荐）：写入 localStorage 前完成净化。比如用户编辑完富文本，调用
localStorage.setItem('post', JSON.stringify({ content: DOMPurify.sanitize(rawInput) }))。一劳永逸，后续读取无需再洗。 -
网关能做的有限但有用：只对那些“确实会经由 HTTP 发送到后端”的 JSON 数据进行防护，例如：
– 在网关配置 JSON body 解析 + 自定义 Filter，用 Jackson 的@JsonDeserialize(using = XssJsonDeserializer.class)全局清洗字符串字段
– 对请求头（如X-User-Note）中的 HTML 片段做 AntiSamy 清洗（参考知识库中 XssUtils 封装）
如果坚持要在网关加一层“兜底”，适用场景是什么
仅适用于：你的前端会把 localStorage 数据作为请求参数（如 query 或 body）主动提交给后端，且该后端接口会将这些数据再次返回给其他用户（形成存储型 XSS 风险）。这时可在网关做两件事：
- 识别特定路由（如
/api/comment/submit），解析 JSON body，对content、title等字段调用 HTML 标签剥离逻辑（如正则<[^>]*>或更安全的Jsoup.clean(input, Whitelist.simpleText())） - 返回响应时，对响应体中可能含用户输入的字段（如
message）强制添加Content-Security-Policy: script-src 'none'响应头，抑制内联脚本执行
本质上，XSS 防护必须匹配数据所处的上下文。localStorage 是前端地盘，守好这道门，得靠前端代码自己动手，而不是指望后端网关越界执法。
