Is it possible to restrict Http Method on B2C login endpoints?

A client I've been working for recently conducted a pentest and the testers flagged up that their Azure B2C custom policy endpoints are vulnerable due to the fact they allow GET as well as POST. Therefore users' email and passwords can be passed as query parameters.

My guess is this isn't possible to change because its Microsoft's underlying technology that specifies what Http protocols are allowed. Just wondering if anyone else has experience of this as the documentation and XML configuration files are a bit of a nightmare.

I've tried applying the metadata property:

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

But it seems this does nothing to restrict the protocols allowed by the endpoints.

This is a false positive "vulnerability" from your pentesting company.

The Authorize endpoint used to initialize the user's journey does not accept a username/password (that'd be the token endpoint - that does only accept a POST but out of the scope of this question).

Let's break down what Azure AD B2C is actually doing.

When you call the authorize endpoint, you are asking to establish an interactive authentication flow. When you enter any data in the forms shown on the screen the data is sent only via HTTP POST to a self-asserted endpoint where it is processed server side (see image below).

If the journey has multiple steps, it then progresses to the next screen using a GET request with a state query parameter (meaning if a user refreshes the page, they can continue the journey without issues), but the data here is not sensitive and definitely does not include passwords.

To answer your question, can you restrict it. No, not without supporting infrastructure. It would be technically possible to add Azure Front Door with a custom domain and block GET requests with some Azure Front Door rules, then block any requests coming direct to b2clogin.com in your custom policy.
Is it worth it... No. Why? Because the OAuth2.0 RFC states GET must be supported and you'd be in violation of the spec:

The authorization server MUST support the use of the HTTP "GET" method [RFC2616] for the authorization endpoint and MAY support the use of the "POST" method as well.