能否限制Azure B2C登录端点的HTTP请求方法？

问题背景 #

客户近期渗透测试发现Azure B2C自定义策略端点同时允许GET和POST请求，存在邮箱、密码通过查询参数泄露的风险。尝试添加元数据配置：

<Item Key="HttpBinding">POST</Item>

但该配置未对端点允许的请求协议起到限制作用，怀疑此限制由微软底层技术决定，想确认是否有同类问题及可行解决办法。

可行解决方案及说明 #

• 区分端点类型处理：不同类型的自定义策略端点对HttpBinding支持逻辑不同。比如用户登录/注册的初始自我断言页面端点，GET请求用于页面初始化加载，POST用于提交数据，这类场景下无法完全禁用GET，但可确保敏感数据仅通过POST传递。
• 精准配置TechnicalProfile：针对REST API集成类端点，需将HttpBinding与SendClaimsIn配合使用，确保敏感数据通过请求体而非URL参数传递，示例配置：

<TechnicalProfile Id="RestApiIntegration">
  <Metadata>
    <Item Key="HttpBinding">POST</Item>
    <Item Key="SendClaimsIn">Body</Item>
  </Metadata>
  <InputClaims>
    <!-- 配置需要传递的声明 -->
  </InputClaims>
</TechnicalProfile>

• 策略层面强化数据传递规则：在自定义策略的用户旅程中，通过ValidationTechnicalProfile或OrchestrationStep配置，强制所有包含敏感数据的操作仅使用POST方法执行，避免敏感字段出现在GET参数中。
• 前端辅助控制：如果渗透测试要求严格禁用GET提交敏感数据，可在自定义UI页面中添加逻辑，拦截GET方式的敏感数据传递，仅允许POST提交，但这属于前端补充措施，需配合后端策略配置。

官方逻辑说明 #

目前Azure B2C自定义策略的部分核心端点（如用户身份验证初始端点）确实保留了GET支持，这是服务初始化流程的必要环节，但核心敏感数据的提交默认已通过POST实现。若测试报告仅因端点允许GET就判定漏洞，可结合上述配置说明，验证敏感数据实际不会通过GET泄露，以此佐证风险可控。

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