常见JavaScript安全漏洞包括DOM型XSS、敏感信息泄露、第三方库隐患和不安全CORS配置；防御XSS需HTML编码、用textContent替代innerHTML、启用CSP；防御CSRF需CSRF Token、SameSite Cookie及二次验证。
JavaScript中主要的安全漏洞集中在用户输入处理、请求发起和客户端数据管理上，XSS和CSRF是最常见也最危险的两类，但还有DOM型注入、不安全存储、第三方依赖风险等不容忽视。
常见的JavaScript安全漏洞有哪些
除了XSS和CSRF，实际开发中高频出现的风险包括：
-
DOM型XSS：不安全地使用
innerHTML、document.write、eval()、setTimeout(string)等API，直接将未处理的用户输入写入DOM或执行字符串代码 -
敏感信息泄露：把Token、密码、用户身份等存进
localStorage或sessionStorage；Cookie未设HttpOnly、Secure和SameSite属性 -
第三方库隐患：引入过时、无人维护或被投毒的npm包（如恶意版本的
lodash、axios），可能自带远程脚本或数据窃取逻辑 -
不安全的CORS配置：后端设置
Access-Control-Allow-Origin: *且允许凭证，导致其他站点可跨域读取敏感响应
如何防止XSS攻击
XSS本质是“不该执行的脚本被执行了”，防御核心是：**不让用户输入变成可执行代码**。
根据ui图生成前端页面
下载
将一个或多个 UI 原型图、线框图、产品截图或设计稿转换为标准化、可直接交付的 PRD 风格文档，供产品、设计、前端和测试共同使用。适用于 Codex 需要分析 PC 网页、桌面端、移动端、响应式页面、独立弹窗、表单、表格、看板、数据大屏或多页面流程截图，还原页面结构与交互，强制套用固定文档模板，抽取跨页面共享规则，或把一组原型沉淀为单页规范文档加整体业务流程文档的场景。不适用于纯视觉审美点评、代码实现、接口设计、埋点方案、竞品分析或无 UI 输入的业务需求创作。
- 所有用户输入渲染前必须做HTML实体编码，比如
<转成<，"转成" - 优先用
textContent而非innerHTML插入内容；若必须渲染HTML，用DOMPurify.sanitize()清洗后再插入 - 启用Content Security Policy（CSP），例如通过HTTP头设置：
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'，禁止外源脚本和内联JS - 富文本场景下禁用
<script></script>、onerror等危险标签和事件属性，用白名单机制过滤
如何防止CSRF攻击
CSRF的关键是“请求是合法的，但不是用户本意发起的”，防御重点是：**确认每个敏感请求确实来自当前用户的真实操作**。
立即学习“Java免费学习笔记（深入）”；
- 服务端为每个用户会话生成唯一、一次性CSRF Token，前端在表单隐藏字段或请求头（如
X-CSRF-Token）中携带，后端严格校验 - 对关键接口（如转账、改密）强制使用POST/PUT/DELETE，并配合Token + Referer检查（注意Referer可伪造，仅作辅助）
- 设置Cookie的
SameSite=Lax或Strict属性，能有效阻止跨站带Cookie的GET/POST请求 - 敏感操作增加二次确认，比如短信验证码或邮箱点击链接，不单靠前端JS拦截
基本上就这些。不复杂但容易忽略——真正起作用的，往往是那个没加textContent的innerHTML，或是忘了设SameSite的登录Cookie。
