我之前处理过好几起Azure WAF误拦截稳定运行应用的案例，结合你遇到的情况——OHDSI Atlas在Azure ISAS上跑了8个月都没问题，最近突然出现PUT/POST请求返回403，触发的都是SQL注入和协议类规则，而且代码完全没动过，咱们可以从这几个方向一步步排查解决：

一、先排查WAF规则的自动更新或阈值变更 #

• Azure WAF的托管规则集（比如OWASP Top 10系列）会定期推送版本更新，哪怕你没主动修改过WAF配置，微软可能在最近两周推送了新的规则版本，导致原本合法的Atlas请求现在被新规则命中。你可以登录Azure门户，找到对应的WAF资源，查看规则集版本，对比问题出现前后的版本差异。
• 检查WAF的规则敏感度阈值是否被调整过（可能是误操作或者自动化配置脚本的变更），比如SQL注入类规则的敏感度被调高，导致Atlas正常的查询参数被误判为恶意注入。

二、深挖被拦截请求的细节，定位误触发点 #

• 赶紧开启WAF的日志记录（可以存储到Log Analytics或者Azure存储账户），筛选出所有返回403的PUT/POST请求，查看具体的请求体、参数、HTTP头部信息，精准定位是哪个字段或者内容片段触发了规则。比如OHDSI Atlas的某些查询接口会传递类似SQL语法的字符串（比如字段名、过滤条件），很容易被WAF的SQL注入规则误识别。
• 针对触发的具体规则ID（比如SQLI-942100这类标识），查看规则的官方描述，确认是否属于典型的误拦截场景——很多通用规则会检测UNION、SELECT这类关键词，但Atlas的正常业务请求里可能会合法使用这些内容。

三、优化WAF规则配置，避免反复“拆东墙补西墙” #

• 别直接全局禁用规则，改用规则排除项：针对特定的URI、请求参数或者HTTP头部，排除触发的规则。比如如果是Atlas的/api/v1/query端点的请求体参数触发了SQL注入规则，就给这个端点添加排除配置，只跳过该规则对这个参数的检测，这样既能保留其他场景的防护能力，又能解决当前的拦截问题。
• 考虑创建自定义允许规则：针对Atlas PUT/POST请求的特征（比如特定的请求头部、参数格式），创建优先级高于托管规则的自定义规则，明确允许这类请求通过。不过要注意自定义规则的范围，别太宽泛，避免引入安全漏洞。
• 可以先把WAF切换到检测模式运行几天，收集所有被拦截的请求，批量确认哪些是误拦截，再统一配置排除项，之后再切回防护模式，这样能减少反复调整的麻烦。

四、验证Azure环境的其他隐性变更 #

• 检查应用服务相关的配置是否有变更：比如TLS版本调整、前端IP地址变更，或者Azure ISAS的网络路由、防火墙规则变更，这些都可能导致请求的协议格式发生细微变化，触发了WAF的协议类规则。
• 确认OHDSI Atlas的依赖服务（比如后端数据库、API网关）是否有版本更新，某些依赖的更新可能会让请求的内容格式发生变化，刚好命中了WAF的规则。

内容的提问来源于stack exchange，提问作者Sunil Ajagekar