为什么谷歌Chrome支持URL中@符号拼接域名的写法？存在安全风险吗？

这个行为本质是Chrome严格遵循通用URL解析规范的结果。

核心解析规则 #

在标准URL结构定义中，@是「用户信息段（userinfo）」和「主机段（host）」的固定分隔符。完整的标准URL结构可以拆解为：
协议://[用户信息@]真实主机地址[:端口]/资源路径?查询参数#锚点
你提到的示例地址https://www.wikipedia.org@google.com，按照规范拆分后的实际解析结果为：

• 协议段：https
• 用户信息段：www.wikipedia.org
• 真实主机段：google.com
  因为Chrome会把主机段的地址作为实际访问目标，因此才会直接跳转到google.com，并不是把www.wikipedia.org识别为要访问的域名。

该结构的最初设计目的 #

URL中设置用户信息段，最早是为了适配早期网络的使用场景：在FTP、早期HTTP服务的访问流程中，用户可以直接在URL里内嵌身份凭证，不需要单独通过弹窗输入账号密码就能完成服务访问，这类写法在网络发展初期是被广泛认可的合规用法。

面对钓鱼风险的防护逻辑 #

你提到的“用户被引导至非预期站点”确实是这个URL结构带来的经典钓鱼漏洞，但Chrome并没有直接将这类URL判定为无效，背后的考量非常务实：

• 如果直接把带@的URL全部判定为无效，会破坏标准兼容性，导致大量仍在合法使用该结构的旧服务、开发场景出现访问故障
• 与其一刀切封停，Chrome针对该风险做了多层防护优化：
  • 地址栏渲染时，永远将真实主机段做高亮显示，前面的用户信息段会使用低对比度灰色展示，不会让用户误以为前面的字符是站点域名的一部分
  • 当检测到用户信息段中包含大众熟知的可信站点关键词时，会弹出显著的安全提示，明确告知用户当前即将访问的真实站点地址，避免被混淆性文本误导
  • 会自动拦截所有在用户信息段内嵌明文账号、密码的访问请求，从根源上避免明文凭证通过URL传输造成的泄露风险

内容的提问来源于stack exchange，提问作者user3500000