前端输入输出与依赖的安全边界
前端安全不是单独加一条响应头，而是把所有不可信输入都沿着进入、处理和输出的路径检查一遍。用户填写的内容、接口返回的富文本、第三方脚本和依赖包都可能成为入口。页面负责减少暴露面，服务端仍要做权限和业务校验，两层不能互相假设对方已经处理完毕。
让文本默认以文本方式呈现
框架模板的默认转义应保持开启。用户输入、模型回复和远程内容只有在确实需要富文本时才进入清洗流程，并使用白名单保留有限的标签与属性。不要把字符串直接赋给 innerHTML，也不要用字符串拼接事件处理器。链接需限制协议，避免看似普通的 URL 跳转到脚本或不受控页面。
富文本还要考虑图片、附件和嵌入内容。图片来源可以通过域名白名单或代理控制，文件下载应交给服务端返回正确的类型与处置方式。前端提示不是安全校验的替代品；涉及权限、额度和资源归属的判断必须由服务端再次确认。
用内容策略逐步收紧来源
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'
这是一条起点，不应直接复制到所有项目。现有应用可能依赖字体、图片、统计或支付等外部来源，应先梳理加载清单，再用 report-only 观察会被拦截的资源。内联脚本和动态注入样式是常见阻碍，最好通过打包和 nonce 等明确机制处理，而不是为了省事放宽为任意来源。
请求安全与会话一起设计
对使用 cookie 的会话，服务端需要校验来源、令牌和敏感操作的意图，前端负责按约定携带令牌并避免跨域误用。不要把访问 token 写进可被任意脚本读取的位置；具体存储方式要结合认证架构评审。退出登录、过期刷新和多标签页同步也会影响会话状态，不能只测试一次成功请求。
依赖更新有自己的风险路径
依赖包同样是输入来源。锁定文件、可信 registry、变更审查和自动化审计能缩小风险，但告警并不等于立即升级：需要确认受影响的运行路径、修复版本和兼容性。第三方脚本尽量减少，必要时记录用途、来源和替代方案。
用针对性用例复核
测试富文本、URL 跳转、文件上传、跨站请求和第三方资源加载。浏览器开发者工具可以检查 CSP 报告与实际加载来源，自动化测试可覆盖常见编码和边界字符。发现问题时记录输入、预期和修复位置，避免用一句“已加安全防护”掩盖仍未覆盖的路径。
把实现条件写回方案里
前文已经分别谈到“让文本默认以文本方式呈现”“用内容策略逐步收紧来源”和“请求安全与会话一起设计”。把它们放在同一条链路里看，才知道各自的前提有没有对齐。界面工程先让状态和数据流说得清楚：先用一个最小输入走完整流程，记录入口参数、关键分支和最终产物。若某一步依赖默认值、环境变量或人工约定，就把它写到调用点附近，不要把判断藏在口头交接里。
如果这部分会被交给同事维护，验收不要只问“有没有完成”。更有用的问题是：看着“用内容策略逐步收紧来源”的结果，能否判断输入是否被正确消费；修改“请求安全与会话一起设计”后，能否找到受影响的地方；撤掉这次改动时，是否会留下半成品。答案不必承诺绝对安全，但应当能对应到代码、配置或现有记录。
收尾时建议把本次选择的限制也留下来。例如“让文本默认以文本方式呈现”暂时覆盖哪些情况，哪些情况仍交给人工或旧路径；“用内容策略逐步收紧来源”依赖什么顺序或资源；“请求安全与会话一起设计”出现时用什么信号提醒。限制写出来并不削弱方案，反而能避免后来的人把局部经验当成通用规则。
真正有用的沉淀，是让读者沿着“让文本默认以文本方式呈现”和“用内容策略逐步收紧来源”找到下一步动作，也让维护者在“请求安全与会话一起设计”出现问题时知道先看哪里。
