javascript无内置安全边界，所有安全依赖开发者对环境、数据流和信任边界的清醒认知；浏览器中js仅有沙箱限制而非特权，易受xss、csrf等攻击，需严格防范输入、凭证、第三方脚本及csp配置。
JavaScript 本身不提供运行时安全边界，所有“安全性”都依赖开发者对执行环境、数据流向和信任边界的清醒认知。浏览器里跑的 JS 没有“沙箱特权”，只有沙箱限制——它能读页面、发请求、存 localStorage，也能被 XSS 注入、被 CSRF 利用、被恶意 script 标签劫持。
为什么 innerHTML 是 XSS 高危入口
直接把用户输入拼进 innerHTML，等于把 HTML 解析权交给了不可信数据。哪怕只显示一条评论，只要含 <script>fetch('/api/steal', {credentials:'include'})</script>，就可能触发会话窃取。
- 替代方案优先用
textContent；需要渲染富文本时，必须用严格白名单解析器（如DOMPurify.sanitize()），而非正则替换或黑名单过滤 -
v-html（Vue）、dangerouslySetInnerHTML（React）同理，它们不是语法糖，是明确的安全免责申明 - 服务端返回 JSON 时，避免在前端用
eval()或JSON.parse(new Function(...))执行动态代码
fetch 默认不带 credentials，但你可能忘了关掉
默认情况下，fetch(url) 不发送 Cookie，看似安全；但一旦设成 {credentials: 'include'}，就等同于开启了跨站请求的会话复用能力。如果后端没校验 Origin 或没设置 SameSite=Strict 的 Cookie，CSRF 就成立。
- 除非明确需要登录态，否则不要加
credentials: 'include' - 敏感操作（如转账、删账号）必须服务端二次验证（如验证码、密码确认），不能只靠前端隐藏按钮或禁用提交
- 检查
Set-Cookie响应头是否包含SameSite=Lax或Strict，旧项目常漏配
第三方脚本加载失控 = 把钥匙交给陌生人
用 document.write、动态 appendChild(script) 或未锁定版本的 CDN 脚本（如 https://cdn.jsdelivr.net/npm/jquery@latest），会让任意代码在你的域下执行。2023 年多个电商站点因加载被污染的统计 SDK 导致支付页键盘记录器注入。
立即学习“Java免费学习笔记（深入）”；
- 禁止使用
document.write（现代浏览器已警告废弃） - 第三方脚本必须指定完整语义化版本（
@3.6.1），并用integrity属性校验 SRI（Subresource Integrity） - 关键页面（如登录、支付）禁用
eval类 API，可通过 CSP 头强制：Content-Security-Policy: script-src 'self' 'unsafe-eval'→ 改为'self'并移除'unsafe-eval'
const script = document.createElement('script');
script.src = 'https://cdn.jsdelivr.net/npm/react@18.2.0/umd/react.production.min.js';
script.integrity = 'sha384-...'; // 必须与实际资源 hash 一致
script.crossOrigin = 'anonymous';
document.head.appendChild(script);
CSP 策略写得再细，只要漏掉一个 unsafe-inline 或放行了 *.evil.com，整个防线就形同虚设。真正难的不是知道漏洞名字，而是每次加一行 JS 时，都问自己：这行代码执行在谁的上下文？它信任谁？谁又能控制它的输入？
