17370845950

前端安全需四重防护：防XSS须禁用innerHTML渲染不可信内容、优先textContent或DOMPurify；防CSRF需SameSite Cookie+后端校验CSRF Token；密钥绝不可硬编码，须后端代理；CSP为必选项，严格配置script-src等策略并用Report-Only调试。

防止 XSS：永远不要用 innerHTML 插入不可信内容

用户输入、URL 参数、后端返回的富文本，一旦直接赋值给 innerHTML，就等于把执行权交给了攻击者。哪怕只显示一条评论，也可能触发 或更隐蔽的窃取 Cookie 行为。

实操建议：

• 优先使用 textContent 渲染纯文本（自动转义）
• 必须渲染 HTML 时，用成熟的库如 DOMPurify.sanitize() 过滤标签和事件属性
• 服务端返回富文本前就应做白名单过滤（前端净化只是第二道防线）
• 避免拼接字符串构造 DOM：el.innerHTML = '' + userInput + '' 是高危写法

防范 CSRF：关键操作必须校验 SameSite 和 CSRF Token

前端本身无法完全阻止 CSRF（因为浏览器会自动携带 Cookie），但可以配合后端大幅降低风险。常见误区是以为「没暴露 API 就安全」——只要目标站点登录态有效，恶意页面就能发起带 Cookie 的请求。

实操建议：

• 将登录态 Cookie 设置 SameSite=Lax（推荐）或 Strict，阻止跨站 POST 请求携带
• 对敏感接口（如转账、改密码），后端必须验证一次性 CSRF token，且该 token 不通过 URL 传递（防泄露）
• 前端在发请求前从 hidden input 或 header 中读取 token，并附在请求体或 X-CSRF-Token 头里
• 避免用 GET 请求执行状态变更操作（如 /api/delete?id=123）

避免敏感信息硬编码：别把 API key、secret 写在前端代码里

任何出现在 JS 文件里的密钥，都等同于公开。攻击者只需打开 DevTools → Sources，就能搜到 sk_live_、api_key: 这类字符串。这不是“理论上可被获取”，而是“必然被获取”。

实操建议：

• 所有密钥、令牌、内部接口地址，必须由后端代理中转，前端只调自己的 /api/proxy/xxx
• 构建时用环境变量注入非敏感配置（如 REACT_APP_API_BASE），但绝不包含密钥
• CI/CD 流水线中禁止将 .env.production 提交到仓库；用 .gitignore 确保其不进入版本控制
• 若必须调用第三方服务（如地图 SDK），优先选支持「Referer 白名单」或「域名绑定」的方案，而非依赖密钥

Content Security Policy 不是可选项，而是必填项

没有 CSP，XSS 利用成本极低；有了合理配置的 CSP，即使存在 XSS 漏洞，攻击者也很难执行脚本或外连窃取数据。它不是修复漏洞的手段，而是限制漏洞影响范围的兜底机制。

实操建议：

• 从严格策略起步：default-src 'self'; script-src 'self'; object-src 'none'，再按需放宽（如允许 CDN 的 JS）
• 禁用 unsafe-inline 和 unsafe-eval —— 即使为了兼容旧代码，也要用 nonce 或 hash 替代
• 通过 HTTP 响应头设置（Content-Security-Policy），比 标签更可靠（后者对内联脚本无效）
• 上线前用 Content-Security-Policy-Report-Only 头收集违规日志，再逐步收紧策略

Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-X68qA...'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; connect-src 'self'; frame-ancestors 'none'; base-uri 'self'; form-action 'self'

前端安全没有银弹。CSP 配错可能让页面白屏，CSRF token 管理不当会导致重复提交，而 DOMPurify 若版本过旧，仍可能放过新出现的绕过手法。真正起作用的，是把安全当成接口契约的一部分——每次加一个 fetch 调用，先问自己：这个响应可信吗？这个参数会进 HTML 吗？这个 Cookie 该不该跨域带？