17370845950

JavaScript安全取决于开发实践而非语言本身，需防范XSS（输入消毒、textContent优先、CSP）、CSRF（SameSite Cookie、CSRF Token）、数据泄露（不硬编码密钥、脱敏缓存）、第三方库风险（npm audit、禁用eval）等。

JavaScript 本身是中立的执行环境，安全性不取决于语言，而取决于代码怎么写、数据怎么处理、服务端怎么配合。很多 Web 攻击不是 JavaScript 的“漏洞”，而是开发者忽略了输入验证、上下文混淆、权限隔离等关键环节。

防范 XSS（跨站脚本攻击）

XSS 的核心问题是：把不可信的数据当作可执行代码渲染了。比如用户提交一段 ，后端没过滤、前端又用 innerHTML 直接插入，就触发了脚本执行。

• 服务端必须对所有用户输入做内容消毒（如转义 为 zuojiankuohaophpcn），尤其输出到 HTML、JS、CSS、URL 等不同上下文时，要使用对应规则（不能只靠全局 replace）
• 前端优先用 textContent 替代 innerHTML；若必须插 HTML，用成熟的库如 DOMPurify 过滤后再插入
• 设置 Content-Security-Policy 响应头（如 default-src 'self'），限制内联脚本和外部资源加载，能大幅降低 XSS 利用成功率

防止 CSRF（跨站请求伪造）

CSRF 不依赖 JS 漏洞，而是利用浏览器自动携带 Cookie 的机制，诱使用户在已登录状态下发起非预期请求。例如点击恶意链接，悄悄转账。

• 对敏感操作（如修改密码、支付）强制使用 POST/PUT/DELETE，并校验 SameSite=Strict 或 Lax 的 Cookie 属性
• 服务端生成一次性 Token（CSRF Token），随表单或 API 请求头（如 X-CSRF-Token）提交，后端比对后才处理
• 避免用 GET 请求执行状态变更操作（如 /api/delete?id=123）

避免 JSON 劫持与敏感数据泄露

早期通过重写 Array 构造函数窃取 JSON 数组响应，现在主流浏览器已修复；但更常见的是前端无意暴露 token、用户信息、内部接口路径等。

• 不要在前端硬编码 API 密钥、JWT 秘钥、数据库连接串等敏感配置
• 避免把完整用户数据（如身份证、手机号）直接塞进全局变量或 localStorage；确需缓存，应脱敏或加密
• 关闭生产环境的 console.log 和错误堆栈（用构建工具剔除或封装日志函数）

安全使用第三方库与动态执行

npm 包可能引入已知漏洞（如 lodash 旧版原型污染），eval()、Function()、setTimeout(string) 更是高危操作。

• 定期运行 npm audit 或使用 Snyk、Dependabot 扫描依赖树，及时升级有 CVE 的包
• 绝对禁止拼接用户输入后传给 eval 或 new Function()；模板引擎（如 Handlebars）启用沙箱模式或预编译
• 用 import() 动态导入模块时，确保模块路径是白名单内的静态字符串，不拼接用户参数

不复杂但容易忽略：安全不是加一道“JS 加密”就能解决的，它需要前后端协同、流程规范、持续审计。一次疏忽可能让整个防护体系失效。