JavaScript安全编程关键在于识别执行上下文、控制数据流向、阻断不可信输入自动求值；需避免innerHTML拼接、慎用eval/JSON.parse、正确配置CSP、防范原型污染，并从首行异步请求起贯彻可信数据假设。
JavaScript 安全编程不是靠加一层“防护库”就能解决的，关键在于识别执行上下文、控制数据流向、阻断不可信输入的自动求值路径。不处理好这三点，DOMPurify 或 CSP 都可能被绕过。
避免 innerHTML + 不可信字符串拼接
这是 XSS 最常见入口。哪怕只插入一个用户昵称，若未转义就写入 innerHTML，攻击者传入 <img src=1 onerror=alert(1)> 就能触发执行。
实操建议：
- 优先用
textContent设置纯文本内容； - 必须插入 HTML 时，用
DOMPurify.sanitize()处理后再赋值，且禁用ALLOWED_TAGS中的script、onerror等危险项； - 绝对不要用
eval()、Function()、setTimeout(string)执行动态字符串； - 模板字符串（
`<div>${userInput}</div>`）不等于安全 —— 它只是拼接，不是自动转义。
谨慎使用 JSON.parse() 解析不可信输入
当后端返回的数据结构不可控（如开放 API、第三方 widget 回调），直接 JSON.parse(input) 可能触发原型污染或配合 __proto__ 注入篡改全局行为。
立即学习“Java免费学习笔记（深入）”；
实操建议：
- 始终用
JSON.parse(input, (key, value) => { if (key === '__proto__' || key === 'constructor') return undefined; return value; })过滤敏感键； - 对已知结构的响应，用
zod或yup做 schema 校验，而非仅靠typeof判断； - 避免把解析结果直接赋给
Object.prototype或任意对象的__proto__。
正确配置 Content-Security-Policy（CSP）响应头
CSP 是最后一道防线，但只靠 meta 标签声明或漏掉 script-src 的 'unsafe-eval' 限制，等于没设。
实操建议：
- 服务端响应头优先于
meta：设置Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self';； - 禁用
unsafe-inline，内联脚本改用nonce或hash（如script-src 'self' 'sha256-abc123...'）； - 启用
report-uri或report-to收集违规日志，别只写default-src 'none'却不监控； -
eval()类函数默认被script-src拦截，但若你写了'unsafe-eval'，CSP 就形同虚设。
防范原型污染与属性劫持
像 lodash.merge、Object.assign、JSON.parse（配合恶意 key）都可能污染 Object.prototype，导致后续所有对象意外拥有攻击者注入的方法或属性。
实操建议：
- 升级到
lodash@4.17.21+，并避免对用户输入调用_.merge({}, userInput)； - 手动合并对象时，显式过滤
__proto__、constructor、prototype； - 在关键逻辑前加防护检查：
if (obj?.__proto__ !== undefined || obj?.constructor !== undefined) throw new Error('Prototype pollution detected'); - 现代项目可启用
Object.freeze(Object.prototype)（注意兼容性，部分老库会报错）。
最常被忽略的一点：安全不是「写完功能再加固」，而是从第一个 fetch().then(res => res.json()) 开始，就要问——这个 res 的 shape 是否完全可控？它有没有可能被中间人篡改？有没有可能被前端缓存污染？这些问题的答案，决定了后续所有防御措施是否有效。
