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、用户信息、内部接口路径等。
立即学习“Java免费学习笔记（深入）”；
- 不要在前端硬编码 API 密钥、JWT 秘钥、数据库连接串等敏感配置
- 避免把完整用户数据（如身份证、手机号）直接塞进全局变量或 localStorage；确需缓存，应脱敏或加密
- 关闭生产环境的
console.log和错误堆栈（用构建工具剔除或封装日志函数）
安全使用第三方库与动态执行
npm 包可能引入已知漏洞（如 lodash 旧版原型污染），eval()、Function()、setTimeout(string) 更是高危操作。
- 定期运行
npm audit或使用 Snyk、Dependabot 扫描依赖树，及时升级有 CVE 的包 - 绝对禁止拼接用户输入后传给
eval或new Function()；模板引擎（如 Handlebars）启用沙箱模式或预编译 - 用
import()动态导入模块时，确保模块路径是白名单内的静态字符串，不拼接用户参数
不复杂但容易忽略：安全不是加一道“JS 加密”就能解决的，它需要前后端协同、流程规范、持续审计。一次疏忽可能让整个防护体系失效。
