JavaScript是XSS和CSRF攻击的主要执行载体，防范需控制数据流向、限制执行上下文、切断攻击链路：XSS防御重在输入过滤、输出编码、执行隔离；CSRF防御核心是校验不可预测且绑定会话的凭证；还需关注第三方库风险、本地存储安全、重定向校验及错误信息泄露。
JavaScript本身不是攻击源头，但它是XSS和CSRF攻击中最常被利用的执行载体。防范重点不在“禁用JS”，而在于控制数据流向、限制执行上下文、切断攻击链路。
防止XSS：堵住“把用户输入当代码执行”的漏洞
XSS本质是服务端未过滤/前端未转义的用户输入，被浏览器当作JS或HTML解析执行。关键在“输入不信任、输出要编码、执行要隔离”。
- 服务端做基础过滤与白名单校验：对用户提交的HTML、URL、JS代码等，优先拒绝非法标签（如
- 前端渲染时严格区分数据与代码：避免innerHTML、document.write、eval、setTimeout(字符串)等危险API；用textContent代替innerHTML显示纯文本；用element.setAttribute('href', url)而非拼接HTML字符串
- 使用现代框架的默认防护机制：React自动转义JSX中的变量、Vue模板中{{ }}默认HTML转义；但v-html、dangerouslySetInnerHTML等显式插入HTML的API仍需人工审核内容来源
- 启用Content-Security-Policy（CSP）头：例如Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval' → 改为 script-src 'self' https://trusted-cdn.com，可大幅降低内联脚本和eval执行风险
防止CSRF：验证“请求确实是用户本意发起”
CSRF利用的是浏览器自动携带Cookie的机制，攻击者诱导用户点击恶意链接或提交表单，以用户身份执行非自愿操作。防御核心是“每个敏感请求附带不可预测且绑定用户会话的凭证”。
- 后端生成并校验CSRF Token：登录后生成唯一token存入session，并下发到前端（如隐藏字段、HTTP头、或JS变量）；所有POST/PUT/DELETE等状态修改请求必须携带该token，服务端比对一致才处理
- 前端正确传递Token：表单提交时通过hidden input传入；AJAX请求统一在headers中加X-CSRF-Token（fetch/Axios可配置interceptor自动注入）；避免token泄露在URL或日志中
- 利用SameSite Cookie属性：设置Cookie时加上SameSite=Lax（推荐）或SameSite=Strict，可阻止跨站请求自动携带Cookie；注意兼容性（IE不支持，旧版Safari需额外处理）
- 关键操作增加二次确认或验证因素：如删除账号、修改密码、大额转账等，要求重新输入密码或短信验证码，不依赖单一token机制
其他常见JavaScript安全盲点
容易被忽略但高频出问题的细节：
立即学习“Java免费学习笔记（深入）”；
- 第三方库风险：定期用npm audit或snyk检查依赖漏洞；避免直接引入CDN上的未锁定版本（如https://cdn.jsdelivr.net/npm/jquery@latest）；优先使用ESM方式按需导入，减少攻击面
- 本地存储敏感信息：localStorage/sessionStorage不能存token、密码、身份证号等；JWT若必须前端存储，应设短期过期+HttpOnly Cookie辅助校验，避免纯前端鉴权
- 重定向与跳转逻辑：location.href = userProvidedUrl 或 window.open(url) 前必须校验URL是否属于白名单域名，防止开放重定向钓鱼
- 错误信息泄露：避免将数据库错误、堆栈、路径等后端敏感信息直接console.log或alert给前端；生产环境关闭详细错误提示，统一返回用户友好消息
基本上就这些。XSS和CSRF不是靠某一个开关就能解决的问题，而是贯穿开发全流程的习惯：输入默认不可信、输出必须编码、状态变更必验身份、第三方资源必审来源。写JS时多问一句“这段代码如果拿到恶意输入会怎样”，很多漏洞就卡在动手之前了。
