Is there any way for ReactJS to send an HTTP request?

Question

We work with a mobile network operator (MNO), they want to add HTTP headers enrichment (HE) feature to the platform.

The MNO is able to inject the user mobile number in the HTTP header and by doing so, the user will no longer be required to login to the platform, we can authenticate him automatically as long as he's using the mobile network of the MNO. The mobile number is encrypted of course.

The MNO has many clients using HE, they use HTTPS, but they can do something like creating a separate landing page, the user lands on it using HTTP, then they grab the HTTP headers from there and forward him to the HTTPS page. tricks like that. obviously, HTTPS is encrypted, so this works over HTTP only. The whole process must be done from the client-side.

The thing is we have a ReactJS PWA, unlike a normal website, if you do any HTTP request, it will give the mixed content error, so even if we create an HTTP landing page, we can't forward the response to the PWA. Is there any solution to that problem?

Answer 1

No. And this is a good thing.

Most work arounds are now blocked by the major browsers, and as you state you will encounter mixed content issues. Firefox was the last to implement this by default and you can see there documentation here.

For those who are unaware of dangers of mixed content the following article gives a reasonable overview: howtogeek. While you state that you feel that as you are encrypting the mobile numbers with AES and that is fine, I suggest you reconsider. Cracking a mobile number is much easier than cracking a password (but don't send those either!) in general and is a key component of identity theft, regardless of whether it can be obtained in other ways.

In my view the correct way to approach this to have the user authenticate normally.

I have included a snippet from rfc2616-sec15 below, I believe it is relevant and encourage you again to consider an alternative.

HTTP clients are often privy to large amounts of personal information (e.g. the user's name, location, mail address, passwords, encryption keys, etc.), and SHOULD be very careful to prevent unintentional leakage of this information via the HTTP protocol to other sources. We very strongly recommend that a convenient interface be provided for the user to control dissemination of such information, and that designers and implementors be particularly careful in this area. History shows that errors in this area often create serious security and/or privacy problems and generate highly adverse publicity for the implementor's company.