JSON.parse()处理用户可控输入存在风险，若后续结合eval、innerHTML等操作会触发XSS或代码执行；需检查location.hash、localStorage等数据源及eval、Function构造器等危险模式。
直接看页面是否在用 JSON.parse() 处理用户可控输入
反序列化漏洞在 HTML 页面里不叫“反序列化”，而是表现为 JSON.parse() 被误用于不可信数据源。只要看到它解析来自 location.search、location.hash、localStorage 或 fetch() 响应体的内容，就存在风险前提——虽然 JS 的 JSON.parse() 本身不会执行代码，但若后续把解析结果喂给 eval()、setTimeout()、innerHTML 或基于属性名动态调用函数（如 obj[ userInput ]()），就构成实际可利用链。
常见错误模式：
-
JSON.parse(decodeURIComponent(location.hash.slice(1)))后直接赋值给obj.callback并调用 - 从 API 拿到 JSON 数据后，用
Object.keys(data).forEach(key => element.innerHTML += `<div>${data[key]}</div>`)—— 若data是服务端未过滤的原始响应，且字段含恶意 HTML，就滑向 XSS；若再结合模板拼接或with()，可能触发更深层逻辑漏洞 - 富文本编辑器导出的 JSON 配置被前端
JSON.parse()后，递归渲染时未校验 key 名（如onerror、onclick）
检查是否有手动反序列化逻辑绕过 JSON 安全边界
真正的危险点常藏在“非标准反序列化”里：比如用 eval('(' + jsonStr + ')') 替代 JSON.parse()，或用 Function 构造器动态执行 JSON 字段值。这类写法会完全绕过 JSON 语法限制，允许执行任意 JS 表达式。
搜索关键词（在 DevTools 的 Sources 面板全局搜索）：
立即学习“前端免费学习笔记（深入）”；
-
eval(.*?\{或eval\(.*?location new Function\(.*?\)-
atob\(.*?\)+ 后续eval（常见于混淆传输的 payload） -
innerHTML =.*?\+.*?\}类字符串拼接（尤其拼接的是未清洗的 JSON 字段）
注意：现代框架（React/Vue）默认不暴露此类接口，但手写管理后台、旧版配置页、埋点 SDK 初始化代码里仍高频出现。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
识别服务端返回 JSON 中是否携带攻击面字段
很多 HTML 页面的“反序列化风险”其实源头在后端。例如：页面初始化时请求 /api/config，返回的 JSON 包含
{"callback": "alert(1)", "template": "<img src="https://img.php.cn/" alt="怎样快速发现HTML页面中的反序列化关联漏洞" />，前端 JS 不加判断直接执行或插入，就等于把服务端的不安全反序列化后果带到了浏览器端。</p>
<p>快速检测步骤：</p>
<ul>
<li>打开 DevTools → Network → 刷页面，筛选 XHR/Fetch 请求，逐个点开 Response 查看是否返回结构化 JSON</li>
<li>重点扫描字段名：包含 <code>callback、handler、render、template、content、html、js 等关键词的键值对
<script>、javascript:、onerror=），记录该接口路径，提交给后端团队核查反序列化逻辑这类问题不是前端能单方面修复的，但前端可加一层白名单校验（如只允许 callback 值为预设函数名数组中的项）。
别忽略 URL 参数被当 JSON 解析的隐蔽场景
有些页面会把整个 URL 参数当作 JSON 对象解析，比如 ?config=%7B%22theme%22%3A%22dark%22%7D → JSON.parse(decodeURIComponent(new URLSearchParams(window.location.search).get('config')))。此时攻击者可构造恶意 config 参数，注入带事件处理器的字符串或原型污染键（如 "__proto__"、"constructor"）。
验证方式：
- 在地址栏手动修改参数为
?config={"x":"y"}，看页面是否正常；再试?config={"onerror":"alert(1)"}，观察控制台报错或 DOM 是否变化 - 若页面崩溃、报
SyntaxError，说明没做 try/catch，属于低级错误；若静默失败或部分生效，说明解析逻辑已嵌入业务流，风险更高 - 特别留意使用了
URLSearchParams+JSON.parse()组合的代码段，这是近年新出现的高危模式
真正容易被忽略的是：这种解析往往不在主逻辑里，而藏在某个第三方统计 SDK 的初始化脚本中，或者埋点配置的异步加载回调里。
