javascript安全漏洞有哪些_怎样防止xss和csrf攻击【教程】

xss是让浏览器执行恶意脚本，csrf是让浏览器代发请求；防XSS重输出净化，防CSRF重请求身份验证。二者必须协同，XSS漏洞可直接绕过CSRF防护。

XSS 和 CSRF 是前端最常被利用的两类安全漏洞，但它们成因、利用方式和防御逻辑完全不同——混淆二者会导致防御失效。直接说结论：**XSS 是“让用户的浏览器执行你的脚本”，CSRF 是“让用户的浏览器替你发请求”；防 XSS 要管住输出，防 CSRF 要管住请求身份**。

为什么 innerhtml + 用户输入 = XSS 高危现场？

很多开发者以为“只要没用 eval 就安全”，其实只要把未过滤的用户数据拼进 HTML，就可能触发反射型或存储型 XSS。比如：element.innerHTML = '

'，当 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 也会被拦截

真实项目中最容易被忽略的，是「XSS 和 CSRF 防御必须协同生效」：比如一个页面存在 XSS 漏洞，攻击者就能用 JS 读取页面上的 CSRF Token 并构造带 token 的请求，让 CSRF 防护彻底失效。所以，**输出净化（XSS）永远是第一道，身份验证（CSRF）是第二道，两者不可割裂**。