XSS是让浏览器执行恶意脚本，CSRF是让浏览器代发请求；防XSS重输出净化，防CSRF重请求身份验证。二者必须协同，XSS漏洞可直接绕过CSRF防护。
XSS 和 CSRF 是前端最常被利用的两类安全漏洞，但它们成因、利用方式和防御逻辑完全不同——混淆二者会导致防御失效。直接说结论：**XSS 是“让用户的浏览器执行你的脚本”，CSRF 是“让用户的浏览器替你发请求”；防 XSS 要管住输出，防 CSRF 要管住请求身份**。
为什么 innerHTML + 用户输入 = XSS 高危现场？
很多开发者以为“只要没用 eval 就安全”，其实只要把未过滤的用户数据拼进 HTML，就可能触发反射型或存储型 XSS。比如：element.innerHTML = '，当 ' + userInput + ''userInput 是 ，脚本立刻执行。
- 真正安全的做法是：优先用
textContent或innerText渲染纯文本；必须插 HTML 时，用DOMPurify.sanitize()过滤，而不是自己写正则 - 模板引擎（如 Vue、React）默认转义插值内容，但
v-html/dangerouslySetInnerHTML会绕过，这类 API 必须加二次人工校验 - 后端返回 JSON 数据给前端时，别在 JS 中用
eval或new Function解析——用JSON.parse()，它天然拒绝可执行代码
CSRF Token 不是加个 hidden input 就完事
只在表单里塞 ，但后端不校验或校验逻辑有缺陷（比如 token 复用、不绑定 session），等于没设防。
- Token 必须一次性且与当前用户 session 强绑定，验证失败应立即销毁该 session
- API 请求（尤其是
POST/PUT/DELETE）也要传 token，建议统一走请求头X-CSRF-Token，比 form data 更难被伪造 -
SameSite=Lax是基础防线，但不能替代 token：它对 GET 请求有效，但对 POST 表单提交或带 body 的 fetch 请求，IE 和旧版 Safari 可能不支持
HttpOnly + Secure + SameSite 三者缺一不可
Cookie 设置看似简单，但漏掉任一属性都可能让防护形同虚设。
-
HttpOnly防止 XSS 后通过document.cookie窃取 session —— 但注意：它不影响 Cookie 自动随请求发送，所以仍需配合 CSRF 防护 -
Secure确保 Cookie 只走 HTTPS，否则中间人可劫持明文传输的 Cookie -
SameSite=Strict最严，但可能导致用户从外部链接跳转时登录态丢失；Lax更实用，覆盖大部分 CSRF 场景（如跨站表单提交），但对POST请求的跨站链接点击仍不拦截
CSP 不是“加个 header 就高枕无忧”
Content-Security-Policy 是最后一道网关，但配置错误反而会阻断正常资源加载，导致功能异常。
立即学习“Java免费学习笔记（深入）”；
- 别直接上
default-src 'none'，先用report-only模式收集违规日志：Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report - 内联脚本（
）和javascript:伪协议默认被禁，但若业务强依赖，得用nonce或hash白名单，而非开放'unsafe-inline' - 第三方 CDN（如 jQuery、统计 SDK）必须显式列入
script-src，否则即使 HTTPS 也会被拦截
