Chrome future update Restrict "private network requests". Will it affect scanning hardware on devices that make local connections?

Kyle Waid picture Kyle Waid · Apr 28, 2021 · Viewed 7k times · Source

I wrote an Angular app and its purpose is a mobile warehouse management system. The app is used primarily on mobile computers with an integrated barcode scanner. They are Honeywell TC60. This device has Android 8 OS and Chrome installed. The Honeywell device comes with a Barcode API that can be implemented in javascript. It does callbacks on port 8080.

I noticed the other day in the web console an error from Chrome: [Deprecation] The website requested a subresource from a network that it could only access because of its users' privileged network position. These requests expose non-public devices and servers to the internet, increasing the risk of a cross-site request forgery (CSRF) attack, and/or information leakage. To mitigate these risks, Chrome deprecates requests to non-public subresources when initiated from non-secure contexts, and will start blocking them in Chrome 92 (July 2021). See https://chromestatus.com/feature/5436853517811712 for more details.

If I understand this correctly, in July the integrated barcode scanner API will be rendered useless and the company will have thousands of dollars in equipment that will no longer work with the integrated scanner API. Requests are made from the device which uses a public and secure domain to a private ip, however it is localhost. localhost you wouldn't think could have a vulnerability. since no outside call is actually being made.

I am not certain this targeted "feature" will break my scanner or not. Should I assume it will? There is no option on the device to require a secure local connection, if that even makes sense.

Answer

Elliott Beach picture Elliott Beach · Apr 28, 2021

You should be able to verify the result by going to chrome://flags/ for a client machine and toggling the setting "Block insecure private network requests." from "default" to "Enabled".

In the case I observe, this error is shown when I make a request from an http internal website to an https internal website. The request fails to execute with said flag enabled.