面向Angular及非Angular客户端的服务如何防范XSS漏洞

原两套接口方案的弊端 #

你提出的两套接口方案可以解决当前问题，但存在明显缺陷：

• 维护成本高：后续业务迭代需要同步更新两套接口逻辑，极易出现数据不一致问题
• 安全风险不可控：批量忽略Angular专属接口的扫描告警，很容易漏过真正存在风险的接口，不符合安全管控的基本原则

推荐落地方案 #

核心原则：服务端只返回原始业务数据，转义责任按消费场景分配，避免一刀切的全量转义，具体可按以下三层落地：

1. 调整安全扫描规则
   首先明确：服务端返回原始字符串本身并不构成XSS漏洞，XSS的触发前提是未转义内容被插入到HTML上下文执行。当前安全工具的告警属于规则误报，这类「服务端必须转义返回内容」的规则原本是针对直接渲染HTML的后端服务设计的，不适用于前后端分离的API接口场景。你可以向安全团队提交规则优化申请，对返回JSON格式的通用接口，关闭对应的XSS告警规则，从根源解决扫描卡点问题。
2. 多消费端适配处理
   不需要修改业务接口逻辑，只需要新增一层统一的转义适配能力：

• 针对Angular等自带XSS防护的客户端：直接调用通用接口即可，完全不需要额外调用domSanitizer.bypassSecurityTrustHtml方法，依赖框架默认转义能力就能兼顾安全和显示正确性
• 针对其他无自主转义能力的客户端：可以在网关层新增可选转义配置，消费端调用接口时在请求头增加标记（比如X-Enable-Html-Escape: true），网关检测到标记后自动对返回的所有字符串字段执行StringEscapeUtils.escapeHtml转义后再返回；也可以单独封装一个通用的HTML转义工具接口，供这类消费端主动调用转换内容。

3. 兜底安全校验
   如果团队无法接受调整扫描规则，可以将服务端的全量转义逻辑替换为攻击特征检测：仅检测返回内容中是否包含<script>、javascript:、onclick=等明确的XSS攻击特征，命中则直接拦截返回错误。这种方式不会转义&、<这类正常字符，不会导致前端二次转义问题，同时也能满足安全扫描的基础管控要求。

额外注意事项 #

• 和非Angular客户端对接时，要在接口文档中明确告知：服务端默认返回原始内容，消费端如果需要将内容插入HTML上下文，需要自行转义或者开启网关转义配置，服务端提供的HTML转义能力仅适配HTML展示场景，若消费端要将内容插入JS、URL等其他上下文，需要自行做对应场景的转义处理。
• 禁止全量使用domSanitizer.bypassSecurityTrustHtml，该方法会完全绕过Angular的XSS防护，一旦上游内容出现恶意脚本，会直接导致攻击生效，风险远高于显示异常问题。

内容的提问来源于stack exchange，提问作者John C