服务端2月19日 17:47
什么是 CSRF 攻击？它需要满足哪些攻击条件？CSRF 是跨站请求伪造，核心不是偷走用户信息，而是借用用户已经登录的身份去发请求。只要目标站点依赖 Cookie 判断登录态，浏览器又会在请求目标域名时自动带上 Cookie，攻击者就可能诱导用户打开恶意页面，让目标站误以为这次修改密码、转账、删除数据是用户本人操作。它通常需要：用户已登录、目标操作靠 Cookie 认证、接口缺少额外意图校验、攻击者能构造可触发请求。
## 追问
### CSRF 为什么能利用 Cookie？
浏览器发送 Cookie 看的是请求目标域名，不看请求是不是用户主动点的。恶意站不能读取 Cookie，但能诱导浏览器带 Cookie 发请求。
### 哪...
乐闻
前端2月19日 17:48
SameSite Cookie 如何防护 CSRF？Strict、Lax、None 怎么选？SameSite Cookie 防护 CSRF 的关键是让浏览器在跨站请求里少带或不带 Cookie。CSRF 成立，是因为用户登录后，攻击站能诱导浏览器向目标站发请求，而浏览器会自动附带登录 Cookie。SameSite 改变的就是这个默认行为。
## 追问
### Strict、Lax、None 怎么选？
Strict 最严格，适合后台、支付、改密等安全优先页面，但会影响从外部链接进入的登录体验。Lax 是多数业务默认选择；None 只给确实需要跨站携带 Cookie 的场景，并必须配 Secure。
### SameSite=Lax 能完全替代 CSRF Token 吗？
不...服务端2月19日 17:48
CSRF 和 XSS 有什么区别？项目里如何区分和防护？CSRF 和 XSS 都是 Web 安全高频问题，但攻击点完全不同。CSRF 是“冒充用户发请求”：攻击者利用用户已登录的 Cookie，让服务器执行用户并不想做的操作。XSS 是“让脚本跑进用户页面”：攻击者把恶意 JavaScript 注入目标站上下文里，读取页面、窃取 Token、调用接口甚至进一步发起 CSRF。区分时记一句话：CSRF 主要骗服务器，XSS 主要控制浏览器。
## 追问
### 两者攻击前提有什么不同？
CSRF 通常要求用户已登录目标站，且敏感接口只靠 Cookie 认证。XSS 要求页面存在输入输出处理漏洞。
### 为什么 XSS 往往更危险？
XSS...服务端2月19日 17:49
Referer 头能防护 CSRF 吗？验证时有哪些局限？Referer 校验能作为 CSRF 防护的一层辅助判断，但不适合当唯一防线。它的做法是对会改变状态的请求，服务端读取 Referer 请求头，确认发起页面来自可信站点；如果来自陌生域名、格式非法或缺失，就拒绝或进入更严格校验流程。它能挡住不少粗糙的跨站表单攻击，但受浏览器隐私策略、Referrer-Policy、HTTPS/HTTP 跳转、代理和客户端实现影响。
## 追问
### Referer 和 Origin 有什么区别？
Origin 只包含协议、域名和端口，不包含完整路径，隐私暴露更少，也更适合安全校验。Referer 信息更完整，但更容易被策略裁剪。
### 没有 Re...服务端2月19日 17:49
双重提交 Cookie 如何防护 CSRF？实现时要注意什么？双重提交 Cookie 防护 CSRF 的核心是：服务端生成随机 token，同时让浏览器把它放在 Cookie 里，并要求前端在表单字段或请求头里再提交一份。真正的同站页面能读到这份非 HttpOnly 的 CSRF Cookie，所以能把 token 放进请求；恶意站点虽然能诱导浏览器自动带上 Cookie，却读不到目标站 Cookie，也就很难提交同一份 token。服务端比较两边是否一致，就能拦住大多数跨站伪造请求。
## 追问
### 它和传统 CSRF Token 有什么区别？
传统 Token 通常保存在服务端 Session 里，请求来了拿提交值和 Session 值比...服务端2月19日 17:52
React、Vue、Angular 中如何正确实现 CSRF 防护？在 React、Vue、Angular 里做 CSRF 防护，关键不是框架语法，而是把服务端发的 CSRF Token 稳定带到每个状态变更请求里。只要登录态依赖 Cookie，前端就要配合后端完成 Token 获取、请求头注入、过期重试和错误提示；如果认证完全使用 Authorization 头，CSRF 压力会小很多，但 XSS 和 Token 存储风险会变高。
## 追问
### 前端应该从哪里拿 CSRF Token？
常见方式是服务端在首屏 HTML meta 标签写入 Token，或提供 /csrf-token 接口初始化获取。也可用非 HttpOnly 的 XSRF-TO...服务端2月19日 17:55
企业级应用如何设计一套可靠的 CSRF 防护架构？企业级 CSRF 防护不要只靠某个接口临时加 Token，应该做成统一安全能力：入口层先挡明显跨站请求，应用层校验会话和 Token，高风险业务再做二次确认。架构上要兼顾多域名、SSO、微服务、灰度发布和审计，否则规则一上线就可能误伤登录、支付或第三方集成。
## 追问
### 校验放网关还是业务服务？
最好两层都做。网关做通用拦截，如 Fetch Metadata 和 Origin 白名单；业务服务做 Token 是否绑定当前用户、租户和操作。
### Token 应该怎么存？
服务端状态 Token 可放 Redis，便于吊销和一次性使用；双提交 Cookie 性能好，但密钥轮换...服务端2月19日 17:56
移动应用需要防 CSRF 吗？如何设计更安全？移动应用通常不容易遇到传统 CSRF，因为原生 App 不会像浏览器那样自动把站点 Cookie 带到任意跨站请求里。但如果 App 使用 WebView、共享 Cookie、深链唤起、第三方登录页，或者后端同时服务 Web 和 App，就仍然要检查“请求是不是用户真实发起”。
## 追问
### 原生 App 用 Bearer Token 还需要 CSRF Token 吗？
大多数情况下不需要，因为 Bearer Token 不会被浏览器自动附加。但 Token 存储不安全会转成账号接管风险。
### WebView 为什么要特别小心？
WebView 容易把 Web 的 Cook...服务端2月19日 17:58
CSRF 防护未来会怎么演进？现在该如何规划？CSRF 防护未来不会只靠一个 Token，而是会变成“浏览器默认安全能力 + 服务端显式校验 + 风险分层”的组合。现在规划时，优先把 SameSite、Origin/Referer、Fetch Metadata 和关键操作 Token 做成统一基线，再根据业务是否跨站、是否嵌入第三方页面、是否有移动端或开放 API 做例外配置。
## 追问
### SameSite 变强后还需要 CSRF Token 吗？
需要。SameSite=Lax 能挡住很多普通跨站请求，但挡不住所有复杂场景。Token 仍适合关键写操作。
### Fetch Metadata 能替代传统校验吗？
不能完...前端2月19日 18:52
RxJS 中 Subject、BehaviorSubject、ReplaySubject 和 AsyncSubject 怎么选？Subject 是既能订阅又能 next 的 Observable，常用来把外部事件推给多个订阅者。Subject 不保存历史值；BehaviorSubject 保存当前值，新订阅者立刻拿到；ReplaySubject 可以回放一段历史；AsyncSubject 只在 complete 时发出最后一个值。选型时先问：新订阅者要不要旧值，要几个旧值，结果是不是只有完成后才有意义。
## 追问
### BehaviorSubject 为什么适合状态？
状态通常需要当前值，比如用户信息、主题配置、表单快照。它要求初始值，所以你必须明确空状态是什么。
### ReplaySubject 有什...