CSRF攻击利用用户已登录状态伪造请求，防御需前后端协同。1. 使用CSRF Token：服务器生成随机令牌并嵌入页面，JavaScript在发送敏感请求前从中获取并附加至请求头或请求体，服务器验证一致性；2. 设置SameSite Cookie属性为Lax或Strict，限制跨站场景下Cookie自动发送；3. 前端通过meta标签或隐藏字段读取Token，结合fetch/axios拦截器统一添加至请求，避免硬编码或不可信来源；4. 禁用自动表单提交，禁用JSONP和宽松CORS策略，防止绕过同源限制。
CSRF（跨站请求伪造）是一种常见的Web安全漏洞，攻击者利用用户在已登录的状态下，伪造其身份向目标网站发起非本意的请求。JavaS
cript在现代前端开发中广泛应用，若未正确处理CSRF防护，可能加剧此类风险。以下是如何在JavaScript环境中有效防御CSRF的实用指南。
理解CSRF攻击机制
CSRF攻击依赖于浏览器自动携带用户凭证（如Cookie）发送请求的特性。当用户登录某站点后，攻击者诱导其访问恶意页面，该页面通过JavaScript或隐藏表单向目标站点发起请求。由于请求附带了用户的合法会话信息，服务器误认为是合法操作。
例如：攻击者构造一个包含如下代码的页面：
@@##@@
或使用JavaScript发起POST请求，用户在无感知的情况下完成转账。
实施有效的CSRF防御策略
防御CSRF的核心在于确保每个敏感请求都附带一个攻击者无法预测的令牌，并由服务器验证该令牌的合法性。
使用CSRF Token- 服务器在返回HTML页面时，嵌入一个一次性随机令牌（CSRF Token），通常放在表单隐藏字段或自定义HTTP头中。
- 前端JavaScript在发送POST、PUT、DELETE等敏感请求前，必须从页面获取该Token并附加到请求中（如请求体或X-CSRF-Token头）。
- 服务器收到请求后，比对Token是否匹配，不匹配则拒绝请求。
- 将关键会话Cookie设置为
SameSite=Strict或SameSite=Lax，可防止浏览器在跨站上下文中自动发送Cookie。 - 推荐使用
SameSite=Lax以兼容大多数导航场景，同时阻止大多数跨域POST请求携带Cookie。
- 不要让敏感操作仅凭Cookie就执行。应要求客户端显式提供额外验证凭证（如CSRF Token）。
- 采用双提交Cookie模式：将CSRF Token同时写入Cookie和请求头，服务器比对两者是否一致。
前端JavaScript中的安全实践
在编写JavaScript代码时，需主动配合后端CSRF机制，确保请求符合安全要求。
- 从页面元数据（如meta标签）或隐藏输入框中读取CSRF Token，避免硬编码或从不可信来源获取。
- 使用fetch或axios等库发送请求时，统一拦截器添加CSRF头，减少遗漏风险。
- 禁用自动提交表单功能，除非明确经过用户交互和Token注入。
- 避免使用JSONP或允许任意域名的CORS配置，这些可能绕过同源策略限制。
基本上就这些。只要前后端协同，合理使用Token和Cookie策略，JavaScript环境下的CSRF风险是可以有效控制的。安全编程不复杂但容易忽略细节。
