JavaScript无安全模式，须主动防御：禁用eval/Function、避免innerHTML拼接、校验URL跳转、强制

CSP策略。

JavaScript 本身没有“安全模式”，写不安全的代码非常容易，而修复往往在漏洞被利用后才开始——关键不是“怎么写安全”，而是“哪些地方默认就不安全，必须主动防御”。

避免 eval() 和 Function() 动态执行字符串

这两者会把任意字符串当作 JS 代码执行，一旦输入来自用户（比如 URL 参数、表单、localStorage），就等于给攻击者开了控制台。

• eval("alert('xss')") 是显式危险，但更隐蔽的是 new Function('return ' + userInput)()
• 替代方案：用 JSON.parse() 解析 JSON 字符串；需要动态逻辑时，用查表法或预定义函数映射
• 注意：setTimeout(string, delay) 和 setInterval(string, delay) 内部也调用 eval，一律改用函数形式

防范 DOM XSS：别用 innerHTML 插入不可信内容

浏览器不会校验你塞进 innerHTML 的字符串是否含恶意脚本， 会直接执行。

• 优先使用 textContent 渲染纯文本
• 若必须插入 HTML（如富文本编辑器输出），用专用库如 DOMPurify.sanitize() 过滤，不要自己正则替换
• 避免拼接字符串生成 HTML：el.innerHTML = '' + userInput + '' —— 即使转义了 和 >，仍可能绕过（比如通过 或事件属性）

谨慎处理用户输入的 URL 和 location 操作

window.location.href = userInput 或 绑定未过滤的链接，可能导致跳转到钓鱼页或执行 javascript:alert(1) 伪协议。

• 对跳转目标做白名单校验：只允许 https:// 开头且域名在可信列表中
• 避免直接赋值 location.href，改用 location.assign(safeUrl) 并确保 safeUrl 经过严格验证
• 禁止在 href 或 src 中拼接用户输入；必须使用时，先用 URL 构造函数解析，再检查 protocol 和 hostname

CSP 不是可选配置，是生产环境强制项

即使代码写得再小心，一个第三方 script 标签或内联事件就能绕过所有前端防护。Content Security Policy 是唯一能从浏览器层面限制资源加载和脚本执行的机制。

• 至少设置 default-src 'self' 和 script-src 'self' 'unsafe-inline' → 立即去掉 'unsafe-inline'，改用 nonce 或 hash
• 禁用 eval 类行为：在 CSP 中加入 script-src 'self' 'unsafe-eval' → 必须删掉 'unsafe-eval'
• 开发时用 Content-Security-Policy-Report-Only 头收集违规，上线前切到 Content-Security-Policy

真正的难点不在知道该做什么，而在于每处 DOM 操作、每次 URL 拼接、每个第三方 SDK 的引入，都要问一句：“这段代码如果拿到恶意输入，会不会成为攻击入口？”——这种条件反射比任何工具都管用。