In a major work through, beginning soon chrome is deprecating direct access to private network endpoints from public websites to protect users CSRF Attack.
This move is specifically designed to block CSRF assaults that target routers and other devices on private networks allowing attackers to redirect users to malicious sites
A two-part phased rollout of the change will begin with Chrome version 98 sending Cross-Origin Resource Sharing preflight requests ahead of private network subresource requests to check the permission from target websites to send HTTP requests with the header Access-Control-Request-Private-Network: true. If permission is granted, the response will carry the header Access-Control-Allow-Private-Network: true. If failed, it will trigger warnings in Dev Tools without otherwise affecting private network requests.
Web admins can test whether their websites will work after this second phase with a command-line argument Access-Control-Allow-Private-Network: true that generates failed fetches for unsuccessful preflight requests.
Chrome Dev team does not see the first phase to break any websites, they urged webmasters to update affected request paths by handling preflight requests on the server side or disabling PNA checks with enterprise policies.
Formerly known as CORS-RFC1918, PNA restricts the ability of websites to send requests to servers on networks that are more private than the network from which the request is initiated.
Chrome has already implemented part of the specification in Chrome 96, since when only secure contexts have been permitted to make private network requests.
The specification also extends the CORS protocol to require websites to explicitly request a grant from servers on private networks before being allowed to send arbitrary requests.
Soon , once after the release the real effect of rolling out this feature will be known . may be from version 101-102 may expect.