Azure使用通配符域名时如何阻止未授权自定义域名访问WebApp

不用纠结App Service 500个自定义域名的配额，那个配额本来就不是为千级以上租户的SaaS场景设计的，直接用下面的可落地方案即可：

方案1：应用层入口校验（最通用，无租户数量上限） #

这是Azure平台上绝大多数多租户SaaS产品的标准实现方式：

• 直接给App Service绑定*.myWebApp.com通配符域名和对应通配符SSL证书，不需要逐个给租户添加自定义域名绑定
• 在应用全局请求中间件的最前端加Host校验逻辑：
  • 提取请求头里的Host字段，解析出子域名前缀（比如请求来源是tenant3.myWebApp.com就提取出tenant3）
  • 拿这个前缀去你的租户缓存/数据库里匹配，判断是不是已经注册生效的合法租户
  • 匹配不到合法租户的请求，直接返回404状态码，或者跳转到官方租户开通页面，不要放行到后续业务逻辑
• 这个方案完全不受平台配额限制，租户规模到十万、百万级都能用，还能灵活扩展租户状态校验（比如欠费停用的租户直接在这层拦截）。

方案2：边缘层拦截（性能更高，减少无效回源） #

如果不想让无效请求打到App Service，可以在App Service前面加一层Azure Front Door做边缘拦截：

• 把*.myWebApp.com的域名解析和SSL证书都绑定到Front Door，不要直接把App Service的IP暴露在公网
• 在App Service的网络访问限制里，配置仅允许Azure Front Door的服务标签流量流入，锁死访问来源，避免有人绕过Front Door直接请求App Service的默认域名
• 在Front Door的规则引擎里配置匹配规则：把请求Host里的子域名前缀和你存储的授权租户列表做匹配，不匹配的请求直接在边缘节点返回403/404，不需要回源到后端App Service，延迟更低，也能节省后端计算资源。

注意避坑 #

• Azure App Service本身没有内置的「通配符域名下自动拦截未授权子域名」的能力，平台层不会维护你的租户授权清单，这个校验逻辑本质是业务逻辑的一部分，必须结合你自己的租户数据实现
• 一定要拦截直接访问App Service默认域名*.azurewebsites.net的请求，避免攻击者绕过你的子域名校验逻辑
• 如果用Front Door做入口，记得开启Host头校验，防止攻击者通过伪造Host头绕过拦截规则

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