前端 Web 安全与 XSS 防护

浏览器会执行页面中的脚本。若攻击者能把可执行内容注入页面，就可能读取页面数据、伪造用户操作或影响其他用户。前端安全需要从数据来源、输出位置和权限边界共同考虑。

一、识别不可信输入

用户输入、接口返回内容、查询参数和第三方内容都应按不可信数据处理。即使接口来自自家服务，也要考虑数据被错误写入或被其他账号提交的情况。

展示普通文本时使用框架默认的文本插值或 DOM 的 textContent，不要把输入拼接成 HTML 字符串再交给浏览器解析。

const message = document.createElement("p");
message.textContent = userProvidedText;
container.append(message);

二、谨慎使用 HTML 注入能力

innerHTML 会把字符串解析为标记语言，若内容中包含恶意脚本或危险属性，就可能形成跨站脚本攻击。只有确实需要富文本时，才使用成熟的清理策略，并限制允许的标签和属性。

手写一组正则表达式通常无法覆盖 HTML 解析规则和浏览器差异。富文本清理应集中在可信模块中，并在进入 DOM 前完成。

三、处理跳转和资源地址

将用户提供的地址用于跳转或资源加载前，要限制协议和目标范围。拒绝脚本协议等可执行内容；对外部新窗口打开场景，应避免新页面反向控制原窗口。

检查解析后的协议和主机信息，而不是用字符串前缀做粗略判断。业务若不需要用户自定义地址，最安全的方案是使用受控标识映射到固定目标。

四、保护身份凭据

可被页面脚本读取的存储位置会受到 XSS 影响。身份凭据的保存方式应结合服务端会话设计和跨站请求防护要求，缩短有效期，并避免写入控制台、分析事件或错误日志。

前端隐藏按钮或菜单只改善界面体验，不能替代服务端权限校验。每个敏感操作都必须由服务端依据当前身份重新授权。

五、防范跨站请求伪造

若身份凭据会随请求自动携带，恶意页面可能诱导浏览器发起用户未授权的操作。服务端应采用合适的 SameSite Cookie、CSRF 令牌和来源检查策略；前端按接口约定附带所需令牌。

敏感操作还应避免仅凭页面打开或简单链接就自动执行，必要时要求用户明确确认。

六、使用安全响应策略

内容安全策略可以限制脚本、样式和其他资源的加载来源，并通过报告帮助发现不安全行为。策略应从观察和逐步收紧开始，避免直接启用不兼容规则导致页面功能中断。

七、不同输出上下文需要不同处理

安全转义取决于数据进入页面的位置。文本节点、属性值、脚本、样式和地址具有不同解析规则，单一的字符串替换不能覆盖所有上下文。优先使用框架安全插值和 DOM 文本 API；确需构造富文本时，采用集中维护的清理策略，白名单控制标签、属性和协议。

不要把未经清理的字符串拼入脚本、样式或事件属性。即便数据来自自家接口，也可能由其他用户提交或因存储缺陷被污染。接口来源可信不等于内容适合直接作为可执行标记。

八、限制危险 HTML 能力

富文本预览、邮件内容和用户描述最容易引入 HTML 注入。清理前要定义产品允许的内容能力，例如是否允许链接、图片、样式和嵌入媒体；清理后还要在真实浏览器中验证解析结果。正则删除几个标签不等同于安全清理。

可在受控环境中启用严格内容安全策略，并逐步减少内联脚本和不必要的资源来源。策略报告帮助发现问题，但部署前要验证登录、编辑器和第三方组件，否则可能阻断正常功能。

九、保护令牌和敏感页面

客户端可访问存储会受到脚本注入影响。凭据生命周期应短、权限应窄，敏感响应避免进入普通缓存和日志。页面隐藏按钮不能替代服务端授权；每次敏感写入都要重新校验当前用户和资源归属。

十、将安全变成代码边界

封装安全渲染、地址校验、身份请求和日志脱敏模块，让业务页面调用受控接口而非自行拼接。第三方脚本需要评估读取页面数据和修改 DOM 的权限，确实不需要时不要引入。

实施中的取舍与复核

输出编码和上下文判断是防止脚本注入的核心。普通文本应作为文本节点渲染，不应先拼成 HTML 再交给浏览器解释；属性、样式、脚本和 URL 上下文的编码规则不同，不能用一个转义函数覆盖所有场景。富文本确有产品需求时，应采用经过审查的允许列表，限制标签、属性和可执行内容，并在展示前清理，而不是只删除几个看似危险的字符串。

客户端校验只能改善体验，不能替代服务端信任边界。攻击者可以绕过界面直接构造请求，因此服务端仍需校验权限、数据格式和业务约束。前端应避免把用户输入放入动态代码执行、模板字符串拼接和危险 DOM 接口；第三方组件产生的 HTML 也要按不可信数据处理。调试时不要在错误日志中记录完整输入、会话令牌或个人信息。

内容策略和浏览器安全机制需要按应用资源结构逐步收紧。先统计页面实际需要的脚本、样式、字体和媒体能力，再制定允许来源；开发阶段出现策略告警时应定位来源而不是无条件放宽。安全策略无法弥补已经存在的危险拼接，但可以限制部分注入后果。上线后观察违规报告，区分真实攻击、旧代码和配置遗漏，避免报告接口本身成为敏感数据收集渠道。

会话安全也与前端交互有关。敏感操作应在界面上展示目标和结果，防止跨站请求伪造需要结合服务端令牌、Cookie 属性及来源校验；退出登录应清理页面内的敏感状态并使旧标签中的操作失效。将认证凭据放入可被脚本读取的长期存储会扩大脚本注入后的影响，存储方案要与服务端会话设计共同评估。

安全回归应覆盖普通文本、特殊字符、富文本粘贴、属性边界和第三方内容，并验证恶意样例只显示为文本或被明确拒绝。建立危险 API 的代码审查规则与依赖升级流程，检查新增渲染能力是否绕过净化。发现风险后还要清理已持久化的不可信内容，单纯修正显示组件并不能消除历史数据里的问题。

复核案例与后续维护

安全修复后还要检查输入数据的存储链路。持久化的评论、名称或富文本可能在另一个页面、邮件预览或管理工具中以不同上下文重新展示；只修主页面渲染入口不足以消除存量风险。数据写入和读取的每个信任边界都要明确净化责任，避免一处净化后被另一个路径再次解释。

安全策略的逐步收紧可先以报告模式了解现有依赖，再修复不符合预期的脚本和资源，最后启用阻断。第三方统计、内联初始化和动态样式通常是迁移难点，拆解成受控能力比添加过宽白名单更可靠。部署变更应覆盖登录页、支付或敏感操作页，避免重要流程被策略误拦截。

依赖中的渲染组件也需安全评估。升级版本前查看危险 HTML 插入能力、模板编译和插件机制；无法确认的数据来源应按不可信输入处理。安全回归用自动化样例验证脚本无法执行，同时人工检查错误信息、富文本保留效果和正常用户内容没有被过度清理。

事故响应要包含临时关闭入口、清理恶意持久化数据、更新缓存内容和通知用户的步骤。只修代码而未移除已经存储的内容，用户下次打开仍会受影响。审计记录应保留修复版本和影响范围，但日志不应再次复制攻击载荷或用户敏感数据。

持续维护要点

安全代码评审可以把不可信输入源和危险输出点列成数据流，检查参数是否经过正确上下文处理。新增富文本、模板和第三方嵌入时重新审查全部展示路径；修复后用正向样例确认普通内容仍能阅读，并清理已经持久化的危险内容。

验收补充

第三方内容展示前应确定数据来源和预期格式。允许的链接文本、图片和富文本能力分别审查，不把一个净化结果跨上下文复用。安全规则更新后用历史内容抽样回放，确认既阻止可执行内容，也没有破坏合法业务文本。

总结

XSS 防护的重点是让不可信数据始终作为数据处理。普通文本使用安全文本接口，富文本采用集中清理，地址限制协议，凭据避免暴露，服务端持续执行权限和请求防护。