webpack-dev-server试图通过强制执行特定的Host标头值来减轻哪些安全风险？
默认情况下，webpack-dev-server仅允许其Host标头指定本地环回地址（localhost，127.0.0.1等）的连接。所有其他主机都会收到以下响应：“无效的主机头”。但是，当然--allowed-hosts / allowedHosts配置可以扩大此限制。
这似乎仅基于Host标头。我可以使用curl设置自定义的Host标头，然后请求成功：
curl -X GET -H "Host: http://0.0.0.0:9001/" http://me.internal.example.com:9001/
所以我很好奇-如果allowedHosts不能阻止连接卷曲或其他自定义用户代理，它将解决什么问题？它似乎只针对使用普通浏览器的普通用户，以保护他们免受错误主机托管的网站的侵害。但是中间人攻击可以轻松地代理连接并覆盖Host标头。
为了防止MITM攻击，您可以使用https（带有浏览器信任的证书）。但是在那种情况下，证书似乎可以单独缓解MITM攻击。
我确定我有什么遗漏，因此不胜感激。
简短版：
攻击是：邪恶的网站使用AJAX从本地webpack-dev-server读取数据。
长版：
这是用于websockets的常规安全机制。
攻击的工作方式如下：您当前在stackoverflow.com上登录。攻击者向您发送包含以下链接的电子邮件：Hey, watch these cute kittens <a href="evil-attacker.com">here</a>。当然，您可以立即单击链接。 evil-attacker.com上的页面包含一个Javascript，该Javascript连接到stackoverflow.com，并以您的名字（因为已登录）写出答案，使您看起来很糟。
Stackoverflow.com可以通过检查创建答案的POST请求的Origin标头为“ stackoverflow.com”来保护您免受此类攻击。在这种情况下，它将是“ evil-attacker.com”，并且该帖子将被拒绝。
但是如果Stackoverflow开发人员已经休假多年并且stackoverflow.com不再维护-没有人实施这种保护该怎么办。
幸运的是，浏览器开发人员并未休假，他们实施了另一种保护措施-同源政策。这仅意味着浏览器将不允许evil-attacker.com连接到stackoverflow.com（不同的域）进行恶意发布。
如果Stackoverflow wants允许某些网站以您的名义运行操作，例如，允许meta.stackoverflow.com显示stackoverflow.com的用户名，则它们必须使用CORS起飞前检查请求。
Websockets是一项新技术-没有使用websockets的旧（未维护）网站。因此，不需要采用同源策略来保护旧网站免受此类攻击。
因此，当指定了Websocket protocol时，他们决定使用上述更简单的Origin检查。
为此，Websocket服务器必须知道可以从哪个来源合法访问它。