Azure拦截User-Agent为Mozilla/5.0发往App Service的POST请求问题

这个拦截是Azure App Service 内置身份验证模块（俗称Easy Auth）默认开启的CSRF（跨站请求伪造）防护机制触发的，和AAD本身的身份校验逻辑无关：

• 该机制会先匹配请求的User-Agent头，只要识别到是浏览器类客户端（匹配Mozilla/*等浏览器特征串），就会对POST/PUT/DELETE等非安全方法的请求做额外校验，GET/HEAD/OPTIONS这类只读请求不会触发校验，这也是所有GET请求正常运行的原因
• 校验逻辑要求：浏览器发起的状态变更请求，必须同时携带合法的会话Cookie（AppServiceAuthSession）和匹配的校验令牌（请求头X-ZUMO-AUTH或表单字段__RequestVerificationToken），二者校验不匹配就直接返回403 Forbidden
• Postman默认的User-Agent不属于浏览器特征范围，不会触发这套CSRF校验逻辑，因此仅携带合法Cookie重放请求就能正常执行，和观察到的User-Agent差异触发拦截的现象完全一致。

根据实际部署场景选对应方案即可：

方案1：保留CSRF防护（推荐，适用于Web前端和API同部署在当前App Service的场景） #

不需要关闭防护，只要在前端发起POST请求时补全校验令牌传递即可，不影响原有安全性：

• 当浏览器访问部署在App Service上的Web页面时，Easy Auth会自动在页面中注入__RequestVerificationToken隐藏字段，也可以直接调用站点下的/.auth/me端点获取当前会话对应的校验令牌
• 发起POST请求时，将获取到的令牌放入X-ZUMO-AUTH请求头，或者作为表单参数__RequestVerificationToken提交，和已有的认证Cookie一起发送即可正常通过校验。

方案2：直接关闭CSRF防护（适用于API独立服务、无浏览器直连表单提交的场景） #

如果确认不需要这套防护，可以直接关闭该规则：

• 方式一：在Azure门户进入对应App Service，打开资源编辑器找到authsettings配置节点，将csrfProtectionEnabled属性值从默认的true修改为false，保存后等待站点配置生效即可
• 方式二：通过Azure CLI执行以下命令修改配置，将占位符替换为实际的资源名即可：

az webapp auth update --name <你的App Service名称> --resource-group <你的资源组名称> --csrf-protection-enabled false

配置生效后，所有请求无论User-Agent是什么，只要携带合法的身份认证凭证就可以正常访问POST接口，不会再被该规则拦截。

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