如何配置后端Front Door自定义规则，仅允许前端流量访问后端API？

直接白名单前端IP失效的核心原因：前端Front Door是全球分布式边缘节点，请求到达后端Front Door时的源IP是前端FD的边缘节点IP，这些IP数量多且动态更新，单IP白名单根本覆盖不全，还会误拦截合法请求。

下面是两个可靠的实现方案，按复杂度和安全性排序：

方案1：验证前端Front Door专属的X-Azure-FDID头（推荐，无需额外配置前端路由） #

每个Front Door实例都有唯一的X-Azure-FDID请求头，前端FD转发请求时会自动带上这个头，后端WAF只需验证这个头的值是否为前端FD的ID即可：

• 步骤1：在Azure门户找到前端Front Door的概览页面，复制属性里的「Front Door ID」（即FDID）
• 步骤2：进入后端Front Door的WAF策略，创建自定义规则：
  • 规则名称：Allow-Only-Frontend-FD
  • 优先级：设为1（确保比默认拦截规则优先执行）
  • 匹配条件：选择「请求头」，头名称填X-Azure-FDID，匹配方式选「等于」，值填刚才复制的前端FDID
  • 动作：选择「允许」
• 步骤3：添加一条兜底拦截规则（优先级设为2）：
  • 规则名称：Block-All-Other-Requests
  • 匹配条件：无需额外条件（默认匹配所有请求）
  • 动作：选择「阻止」

方案2：自定义专属验证头（灵活性更高） #

如果需要更自定义的验证逻辑，可以让前端FD在转发请求时添加一个只有你知道的自定义头，后端WAF检查这个头的存在性和正确性：

• 步骤1：进入前端Front Door的路由规则，编辑目标路由的「转发配置」，添加自定义请求头（比如X-Valid-Frontend: YourSuperSecretKey123，密钥要足够复杂，避免被猜测）
• 步骤2：在后端Front Door的WAF策略创建自定义规则：
  • 规则名称：Allow-Valid-Frontend-Header
  • 优先级：1
  • 匹配条件：「请求头」等于X-Valid-Frontend，值填你设置的密钥
  • 动作：「允许」
• 步骤3：添加兜底拦截规则（优先级2），动作设为「阻止」

测试验证 #

• 用Postman直接请求后端API：不带对应头或头值错误，应该被WAF拦截
• 正常通过前端页面发起请求：应该能正常访问后端API

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