Chrome to bolster CSRF protections with CORS preflight checks on private network requests

Phased rollout begins from Chrome 98 with DevTools warnings of failed preflight requests

Chrome is deprecating direct access to private network endpoints from public websites in order to protect users from cross-site request forgery (CSRF) attacks.

Part two of the browser’s implementation of the Private Network Access (PNA) specification, the move is specifically designed to block CSRF assaults that target routers and other devices on private networks.

“These attacks have affected hundreds of thousands of users, allowing attackers to redirect them to malicious servers,” explained Chrome software engineer Titouan Rigoudy and Google developer advocate Eiji Kitamura in a blog post.

Preflight screening

A two-part phased rollout of the change will begin with Chrome 98 – expected to land in early February – sending Cross-Origin Resource Sharing (CORS) preflight requests ahead of private network subresource requests.

RELATED Same-origin violation vulnerability in Safari 15 could leak a user’s website history and identity

Regardless of the private network request’s method and mode, the preflight requests will request permission from target websites to send HTTP requests with the header . If permission is granted, the response will carry the header .

“This ensures that the target server understands the CORS protocol and significantly reduces the risk of CSRF attacks,” said Rigoudy and Kitamura.

Phased rollout

Preflight failures will trigger warnings in DevTools without otherwise affecting private network requests.

However, from Chrome 101 at the earliest – contingent on the results of first-phase compatibility data and first contacting the largest affected websites – rejected preflight requests will be blocked.

Web admins can test whether their websites will work after this second phase with a command-line argument – – that generates failed fetches for unsuccessful preflight requests.

Catch up with the latest browser security news

Although the Chrome team does not expect the first phase to break any websites, they nevertheless urge webmasters to update affected request paths by handling preflight requests on the server side or disabling PNA checks with enterprise policies.

A deprecation trial lasting at least six months will begin at the outset of phase two to allow affected websites to request a time extension.

PNA implementation timeline

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 Cross-Origin Resource Sharing (CORS) protocol to require websites to explicitly request a grant from servers on private networks before being allowed to send arbitrary requests.

The Chrome team is “tentatively aiming” to introduce phased rollouts for extending PNA checks further to cover dedicated, shared, and service web workers from Chrome 100, and to cover navigations, including iframes and popups, from Chrome 102.

READ MORE Firefox fixes fullscreen notification bypass bug that could have led to convincing phishing campaigns