防范XSS需输入过滤、输出编码与CSP策略；防御CSRF应使用Anti-CSRF Token、SameSite Cookie及来源验证；前后端协同强化安全，持续审计确保防护有效。
面对Web应用日益复杂的攻击手段，JavaScript安全成为开发中不可忽视的一环。XSS（跨站脚本攻击）和CSRF（跨站请求伪造）是两种常见且危害较大的安全漏洞。有效防护这两类攻击，需要从前端、后端以及整体架构层面协同设计。
防范XSS攻击：阻止恶意脚本注入
XSS攻击的核心是攻击者将恶意脚本注入页面，当其他用户浏览时被执行。常见的形式包括反射型、存储型和DOM型XSS。
防护策略应从输入处理、输出编码和内容安全策略三方面入手：
- 对用户输入进行严格校验与过滤：在服务端和前端均应对用户提交的内容进行检查，移除或转义HTML标签和JavaScript代码。可使用成熟的库如 DOMPurify 进行安全清理。
- 输出时进行上下文相关的编码：根据内容插入的位置（HTML、属性、JavaScript、URL等），采用相应的编码方式，如 HTML 实体编码或 JavaScript 转义。
- 启用Content Security Policy（CSP）：通过设置HTTP头 Content-Security-Policy，限制页面只能加载指定来源的脚本，禁止内联脚本执行（如 onclick、标签），大幅降低XSS成功概率。
防御CSRF攻击：确保请求来源可信
CSRF利用用户已登录的身份，在其不知情的情况下发起非法请求，例如修改密码或转账。
立即学习“Java免费学习笔记（深入）”；
关键在于验证请求是否由用户主动发起，而非被第三方诱导：
- 使用Anti-CSRF Token机制：服务器为每个会话生成唯一的token，并嵌入表单或通过JS注入请求头。每次敏感操作都需验证该token，攻击者无法获取此值，从而无法构造合法请求。
- 验证Referer和Origin头：检查请求来源是否属于可信域名。虽然可被绕过，但作为辅助手段仍有一定价值。
- 采用SameSite Cookie属性：设置Cookie时添加 SameSite=Strict 或 Lax，防止浏览器在跨站请求中自动携带Cookie，有效阻断多数CSRF攻击路径。
前后端协同提升整体安全性
单一措施难以完全抵御攻击，必须结合前后端共同构建防线：
- 前端避免使用 innerHTML 或 dangerouslySetInnerHTML，优先使用 textContent 或安全的渲染方法。
- 敏感操作建议增加二次确认或验证码，提升攻击成本。
- API接口默认拒绝跨域请求，仅对明确授权的源开放 CORS 策略。
- 定期进行安全审计和自动化扫描，及时发现潜在风险。
基本上就这些。XSS和CSRF虽常见，但只要遵循规范、合理配置策略，就能有效规避。安全不是一次性的任务，而是贯穿开发、测试到上线的持续过程。不复杂但容易忽略的是细节——比如一个未转义的变量输出，可能就是突破口。
