前端安全需四重防护：防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 该不该跨域带？ 
