CSRF（跨站请求伪造）
伪造一个恶意的请求，诱导你的浏览器自动携带上合法的 Cookie，从而发送恶意敏感请求。
就是攻击者盗用了你的身份，以你的名义发送恶意请求；
通过cookie，referer字段，token，验证码，加密等等来防范； CSRF-TOKEN;
CSRF token防范原理
服务端会维护一个会话token，也就是csrf-token，它一般存储在客户端的js内存当中，同源策略限制，别的域名无法获取，依次来进行防范。
客户端的js内存，比如全局的js变量，zustand等等；
为什么不建议存在Cookie / localStorage / sessionStorage 里？
csrf设计的目的就是为了防止浏览器自动携带Cookie的特性，导致里面的session_token泄露，从而发布恶意请求。所以肯定不能存在Cookie当中。
为了防范XSS攻击，也不能存在Storge当中。
你知道“双重提交 Cookie”模式吗？它和基于 Session 的 Token 模式有什么优缺点？
哦哦，这种就是我之前学的csrf验证方式，
服务端不再存储csrf-token， 而是客户端获取Cookie之后，把他手动添加到请求头中，服务端只比较 请求头和Cookie。安全性稍弱一点。
安全性稍弱：它依赖于“攻击者无法修改同源的 Cookie”这一假设。如果网站存在可以影响 Cookie 的漏洞（如子域名 XSS），则该机制可能被绕过。
GET请求需要吗？
如果你正确使用GET请求（读，且只是读），那么不需要。 如果有其他副作用，那还是要。
XSS（跨站脚本攻击）
本质是在你的网站上执行了攻击者的代码
- 存储型 XSS：攻击者将恶意代码提交到网站数据库，其他用户加载页面时执行。
示例：攻击者在论坛提交 <script>stealCookie()</script>，其他用户加载页面时执行就会被盗取cookie。
反射型 XSS：攻击者构造特殊的 URL，用户点击后，网站解析 URL，恶意代码执行。
DOM 型 XSS：前端脚本操作 DOM 时，未对用户输入进行过滤，导致恶意代码执行。
框架本身都是转义进行防范，不使用危险操作即可，比如innerHTML，eval等等； 比如React的dangerouslySetInnerHTML；
XSS防范
- 使用httpOnly, 防止脚本读取cookie。（存储在js内存中， 然后双cookie验证也行）
- 避免使用React的dangerouslySetInnerHTML，如果非要用，需要用成熟的库进行净化，移除危险的标签。
SQL注入
前端一般无法完全防御，需要后端配合，一般使用一个ORM（不手动写sql的库）管理就够了；
问题
在前后端分离的架构下，你通常会把 CSRF Token 存储在哪里？为什么不建议存在 Cookie 或 localStorage 里？
你知道“双重提交 Cookie (Double Submit Cookie)”这种 CSRF 防御模式吗？它和基于 Session 的 Token 模式有什么优缺点？
- 就是比较请求头和cookie里面的是否相同，优点是依然依然无状态且不用服务端存储。缺点是不够安全，依然可能被很深的xss获取。
现代浏览器提供的 SameSite Cookie 属性，能在多大程度上缓解甚至替代 CSRF Token 的作用？它有哪些局限性？
对于 GET 请求，我们通常需要进行 CSRF 防护吗？为什么？
延伸问题
- 你刚刚提到了 CSP，你能详细解释一下 script-src 'self' 和 nonce 的区别和适用场景吗？
- 除了 dangerouslySetInnerHTML，在 React/Vue 中还有哪些场景或 API 可能会无意中引入 XSS 风险？
- 如果一个富文本编辑器允许用户自定义样式（比如颜色和字体大小），但要防止 XSS，你的净化（Sanitization）策略会是怎样的？你会允许哪些 HTML 标签和 CSS 属性？
- DOM 型 XSS 和反射型 XSS 的核心区别是什么？为什么说 DOM 型 XSS 更难被传统的 Web 应用防火墙（WAF）检测到？ 在单页面应用（SPA）中，XSS 漏洞的风险和传统多页面应用相比，有什么异同？