With #318 the Access-Control-Allow-Private-Network was introduced to this package, which now sets the header seemingly unconditionally when Access-Control-Allow-Private-Network: true is set in the client request.
This renders the whole private network requests initiative useless as it basically restores the "classic" behavior of allowing all requests as before introducing this feature by Chrome. For more information, please check the standard.
As the Chrome devs have introduced this feature as a security measure, I would consider this a security vulnerability. The newly introduced security measure is getting explicitly deactivated by this package, probably unknown to most users of this package.
My recommendation is to allow users of this package to decide whether the Access-Control-Allow-Private-Network is being set. This might incur breaking changes in some projects, but should be fine for most as it only impacts projects which are called from publicly available web pages hosted in private networks. For example, in some projects we are using this package, we would like to not set the Access-Control-Allow-Private-Network header as we are hosting an internal API with this library, but it does not have to be available to external web pages. As I would propose to be secure by default, this header should not be sent by default.
JoshuaPeddle
commented
2 months ago
With #318 the
Access-Control-Allow-Private-Networkwas introduced to this package, which now sets the header seemingly unconditionally whenAccess-Control-Allow-Private-Network: trueis set in the client request.This renders the whole private network requests initiative useless as it basically restores the "classic" behavior of allowing all requests as before introducing this feature by Chrome. For more information, please check the standard.
As the Chrome devs have introduced this feature as a security measure, I would consider this a security vulnerability. The newly introduced security measure is getting explicitly deactivated by this package, probably unknown to most users of this package.
My recommendation is to allow users of this package to decide whether the
Access-Control-Allow-Private-Networkis being set. This might incur breaking changes in some projects, but should be fine for most as it only impacts projects which are called from publicly available web pages hosted in private networks. For example, in some projects we are using this package, we would like to not set theAccess-Control-Allow-Private-Networkheader as we are hosting an internal API with this library, but it does not have to be available to external web pages. As I would propose to be secure by default, this header should not be sent by default.