前端输入安全与依赖审计
前端安全依赖分层防护。没有任何单一配置能替代输出编码、权限校验和依赖更新。
把不可信内容当作数据
默认使用框架的转义能力；确需渲染 HTML 时，先在服务端或可信的客户端库中进行白名单过滤。避免把用户输入直接赋给 innerHTML。
CSP 起点
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'
CSP 需要结合现有资源来源逐步收紧，并通过 report-only 模式观察影响。CSRF 防护还应由服务端校验请求来源和令牌。
验证建议
对富文本、URL 跳转、上传文件和第三方脚本做针对性测试；在 CI 中运行现有依赖审计，并按项目风险流程处理告警。
把 富文本输入与第三方依赖 放回一次真实改动里
做前端方案时，我通常先找一个会被频繁改动的页面或组件，而不是先把目录结构整体翻新。把这次改动涉及的入口、数据来源、使用方和退出条件写在同一张小清单里。这样评审时讨论的是“这处改动会让谁多拿一份状态、谁需要升级、出了问题怎样关掉”，不会停留在组件名称或框架偏好上。
代码合并前不妨把变更放到一个较慢的设备和较差的网络下走一遍。此时暴露出来的往往不是某个 API 写错，而是加载顺序、占位内容、焦点位置和失败后的恢复路径没有被认真设计。截图只能说明一个静态瞬间；连续操作、返回再进入、切换账号这些动作更容易发现状态是否真的被收口。
复核时看可观察的行为
复核不需要堆很多指标。选几条能说明问题的记录即可：一次正常完成的操作、一次被取消或失败的操作，以及一次刷新页面后的结果。把浏览器版本、构建产物、输入条件和观察到的现象留下来。若改动涉及缓存或异步请求，要刻意验证旧请求晚到时不会覆盖新结果；若涉及交互控件，则检查键盘操作和读屏文本没有随着视觉调整消失。
上线后也不要因为页面“看起来没问题”就把观察关掉。先约定一个短时间的观察范围，留意错误边界、资源加载失败和用户实际的退出位置。发现异常时，优先还原当时的输入与版本，再决定回滚还是补丁。这样的记录不华丽，却能让下一位接手的人知道这套 富文本输入与第三方依赖 在什么条件下被验证过，哪些情况尚未覆盖。
不要把边角情况留给线上
关于输入安全的结论应当带着条件保存。它依赖的版本、输入形态和资源限制一变，过去的现象可能就不再成立。与其给出绝对判断，不如说明本次观察覆盖了哪些路径、刻意没有覆盖哪些路径。后续改动时先复用这些条件，再决定是否需要重新验证。
这类补充不会让方案显得更复杂，反而能避免讨论停留在抽象词上。真正要确认的是：输入变化后谁负责判断，结果写到哪里，失败会留下什么证据，以及操作人能否在不猜测的情况下恢复现场。
依赖审计产生告警时，先看实际引入路径和可达性，再按项目流程处置。盲目升级可能破坏构建，忽略告警同样会留下风险。
安全策略调整后查看报告中真实被拦截的资源，再逐项决定放行或替换，避免扩大脚本来源。
