Angular调用.NET API触发Remote File Inclusion in JSON Data报错求助

核心问题分析 #

你的情况是Postman请求正常，但Angular前端调用同一路径API时触发WAF的JSON违规拦截，提示remote-file-inclusion-in-json，说明WAF认为你的Angular请求JSON中存在符合攻击特征的内容，但Postman的请求没有。差异肯定出在两者的请求细节上，按以下步骤排查：

具体排查步骤 #

• 对比请求体的差异
  打开浏览器F12的Network面板，找到触发拦截的API请求，查看Payload里的JSON内容，和Postman中发送的请求体逐行对比：

  • 检查是否存在pwd、ID这类被WAF标记的键名，是否是代码中误加的（比如复制粘贴时带进来的冗余字段）；
  • 检查键名的大小写、拼写是否和Postman一致（比如Postman用user_id，Angular用ID，而WAF规则对ID这类通用键名误判）。

• 检查请求头的差异
  同样在Network面板查看Angular请求的请求头，和Postman的请求头对比：

  • 确认Content-Type是否都是application/json，有些WAF会拒绝非标准JSON格式的请求；
  • 检查是否存在额外的请求头（比如Angular默认带的X-Requested-With: XMLHttpRequest），部分WAF对这类头有特殊规则，可尝试在Angular请求中移除该头测试。

• 验证JSON序列化的差异
  Angular默认用JSON.stringify()序列化请求体，而Postman的序列化逻辑可能不同：

  • 检查是否存在特殊值（比如日期对象、空值、特殊字符）在Angular序列化后生成了奇怪的JSON结构，触发WAF规则；
  • 尝试手动构造简单的JSON请求体（比如只传必要的字段）测试，看是否还会触发拦截，逐步排查是哪个字段或格式导致的。

• 检查WAF规则的误判可能
  你遇到的misc-commands规则匹配ID、pwd这类常见字符串，很可能是WAF规则过于严格导致误判：

  • 尝试修改键名（比如把ID改成userId），看是否能绕过拦截；
  • 联系运维或负责WAF的人员，确认当前规则是否针对这类通用键名有过度拦截，是否需要调整规则。

• 排查Angular请求拦截器
  如果你的Angular应用配置了HTTP拦截器，检查拦截器是否在请求体中添加了额外字段（比如某些全局参数），这些字段可能刚好匹配WAF的攻击特征，导致被拦截。

内容的提问来源于stack exchange，提问作者abid Hussain