JavaScript安全编码的核心是不信任任何外部输入，对用户数据做严格过滤和转义，同时利用现代浏览器机制隔离执行环境。XSS和CSRF是Web前端最常见、危害最大的两类攻击，防御需从前端、后端协同入手，不能只靠单侧措施。
防范XSS：从输出上下文决定转义方式
XSS本质是恶意脚本被当作HTML/JS/CSS执行。关键不是“过滤输入”，而是“在输出时按上下文正确转义”：
-
HTML内容中插入用户数据：用
textContent代替innerHTML；若必须用innerHTML，先通过DOMPurify等库清理HTML，不自己写正则过滤 -
HTML属性中插入数据：如
<div data-id="USER_INPUT">，需对双引号、尖括号、&等字符做HTML实体编码（<code>",<,&） -
JavaScript字符串中嵌入数据：如
var name = "USER_INPUT";，必须用JSON序列化（JSON.stringify()），不要拼接字符串 -
URL参数中插入数据：用
encodeURIComponent()，避免直接拼进href或src -
后端必须校验CSRF Token：为每个会话生成唯一Token，表单提交或AJAX请求时带上（如放在header
X-CSRF-Token或 body字段），后端比对并一次性使用 -
前端正确携带Token：登录成功后从响应头或接口获取Token，存在
sessionStorage；所有敏感请求（POST/PUT/DELETE）自动注入Token，可用Axios拦截器统一处理 -
合理使用SameSite Cookie属性：将身份Cookie设为
SameSite=Lax（默认现代浏览器行为），可拦截大部分跨站POST请求；敏感操作进一步设为Strict - 避免GET请求修改状态：删除、支付、权限变更等操作禁用GET，防止被图片链接、重定向等方式触发
-
启用CSP（Content Security Policy）：通过HTTP响应头
Content-Security-Policy限制脚本来源，禁止eval、内联脚本和未授权域名加载，大幅降低XSS危害 -
避免危险API滥用：禁用
eval()、Function()、setTimeout(string)、setInterval(string)；用JSON.parse()代替eval()解析JSON - 敏感操作二次确认：删除账户、转账、修改邮箱等关键动作，前端弹窗确认+后端再次校验Token和用户意图（如短信/邮箱验证码）
- 最小权限原则：前端仅请求必要数据，避免暴露敏感字段（如token、密码哈希）到全局变量或console日志
阻断CSRF：服务端验证 + 前端配合
CSRF利用用户已登录状态发起非授权请求，防御重点是确认“这个请求确实是用户本意发出的”：
增强JavaScript运行时防护
即使有基础防御，也要减少攻击面和提升容错能力：
立即学习“Java免费学习笔记（深入）”；
安全不是功能开关，而是贯穿开发流程的习惯。每次拼接用户数据前问一句“它会在哪里被解释执行”，每次发请求前确认“服务端是否验证了身份和意图”。不复杂但容易忽略。
