前端输入输出与依赖的安全边界前端安全不是单独加一条响应头而是把所有不可信输入都沿着进入、处理和输出的路径检查一遍。用户填写的内容、接口返回的富文本、第三方脚本和依赖包都可能成为入口。页面负责减少暴露面服务端仍要做权限和业务校验两层不能互相假设对方已经处理完毕。让文本默认以文本方式呈现框架模板的默认转义应保持开启。用户输入、模型回复和远程内容只有在确实需要富文本时才进入清洗流程并使用白名单保留有限的标签与属性。不要把字符串直接赋给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 报告与实际加载来源自动化测试可覆盖常见编码和边界字符。发现问题时记录输入、预期和修复位置避免用一句“已加安全防护”掩盖仍未覆盖的路径。把实现条件写回方案里前文已经分别谈到“让文本默认以文本方式呈现”“用内容策略逐步收紧来源”和“请求安全与会话一起设计”。把它们放在同一条链路里看才知道各自的前提有没有对齐。界面工程先让状态和数据流说得清楚先用一个最小输入走完整流程记录入口参数、关键分支和最终产物。若某一步依赖默认值、环境变量或人工约定就把它写到调用点附近不要把判断藏在口头交接里。如果这部分会被交给同事维护验收不要只问“有没有完成”。更有用的问题是看着“用内容策略逐步收紧来源”的结果能否判断输入是否被正确消费修改“请求安全与会话一起设计”后能否找到受影响的地方撤掉这次改动时是否会留下半成品。答案不必承诺绝对安全但应当能对应到代码、配置或现有记录。收尾时建议把本次选择的限制也留下来。例如“让文本默认以文本方式呈现”暂时覆盖哪些情况哪些情况仍交给人工或旧路径“用内容策略逐步收紧来源”依赖什么顺序或资源“请求安全与会话一起设计”出现时用什么信号提醒。限制写出来并不削弱方案反而能避免后来的人把局部经验当成通用规则。真正有用的沉淀是让读者沿着“让文本默认以文本方式呈现”和“用内容策略逐步收紧来源”找到下一步动作也让维护者在“请求安全与会话一起设计”出现问题时知道先看哪里。 前端输入输出与依赖的安全边界前端安全不是单独加一条响应头而是把所有不可信输入都沿着进入、处理和输出的路径检查一遍。用户填写的内容、接口返回的富文本、第三方脚本和依赖包都可能成为入口。页面负责减少暴露面服务端仍要做权限和业务校验两层不能互相假设对方已经处理完毕。让文本默认以文本方式呈现框架模板的默认转义应保持开启。用户输入、模型回复和远程内容只有在确实需要富文本时才进入清洗流程并使用白名单保留有限的标签与属性。不要把字符串直接赋给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 报告与实际加载来源自动化测试可覆盖常见编码和边界字符。发现问题时记录输入、预期和修复位置避免用一句“已加安全防护”掩盖仍未覆盖的路径。把实现条件写回方案里前文已经分别谈到“让文本默认以文本方式呈现”“用内容策略逐步收紧来源”和“请求安全与会话一起设计”。把它们放在同一条链路里看才知道各自的前提有没有对齐。界面工程先让状态和数据流说得清楚先用一个最小输入走完整流程记录入口参数、关键分支和最终产物。若某一步依赖默认值、环境变量或人工约定就把它写到调用点附近不要把判断藏在口头交接里。如果这部分会被交给同事维护验收不要只问“有没有完成”。更有用的问题是看着“用内容策略逐步收紧来源”的结果能否判断输入是否被正确消费修改“请求安全与会话一起设计”后能否找到受影响的地方撤掉这次改动时是否会留下半成品。答案不必承诺绝对安全但应当能对应到代码、配置或现有记录。收尾时建议把本次选择的限制也留下来。例如“让文本默认以文本方式呈现”暂时覆盖哪些情况哪些情况仍交给人工或旧路径“用内容策略逐步收紧来源”依赖什么顺序或资源“请求安全与会话一起设计”出现时用什么信号提醒。限制写出来并不削弱方案反而能避免后来的人把局部经验当成通用规则。真正有用的沉淀是让读者沿着“让文本默认以文本方式呈现”和“用内容策略逐步收紧来源”找到下一步动作也让维护者在“请求安全与会话一起设计”出现问题时知道先看哪里。 
