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 的字符串是否含恶意脚本，<img src=x onerror=alert(1)> 会直接执行。
- 优先使用
textContent渲染纯文本 - 若必须插入 HTML（如富文本编辑器输出），用专用库如
DOMPurify.sanitize()过滤，不要自己正则替换 - 避免拼接字符串生成 HTML：
el.innerHTML = '<div>' + userInput + '</div>'—— 即使转义了<和>，仍可能绕过（比如通过或事件属性）
谨慎处理用户输入的 URL 和 location 操作
window.location.href = userInput 或 <a href="..."> 绑定未过滤的链接，可能导致跳转到钓鱼页或执行 javascript:alert(1) 伪协议。
立即学习“Java免费学习笔记（深入）”；
- 对跳转目标做白名单校验：只允许
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 的引入，都要问一句：“这段代码如果拿到恶意输入，会不会成为攻击入口？”——这种条件反射比任何工具都管用。
