我知道 protocol-relative URLs ,这通常是在可能使用 HTTP 或 HTTPS 加载的页面上提供脚本或其他资源的正确解决方案。
但是,我有一个脚本,我希望始终通过 HTTPS 提供服务,即使它正在加载的页面是通过 HTTP 提供的。撇开混合 HTTP 和 HTTPS 内容的明显潜在安全问题(即,对通过 HTTP 提供的某些脚本的 MITM 攻击理论上可以用于注入(inject)用于从通过 HTTPS 提供的脚本中读取内容的漏洞利用代码),这是一个糟糕的问题吗?出于任何其他原因的想法?例如,这是否会在任何旧版本的 IE 中导致混合内容警告?
最佳答案
不!至少,在任何仍然流行的浏览器上都不是。
Paul Irish(Google Chrome 的开发者之一,也是一位非常有名的编程博主和开源贡献者)在他 2010 年的博文 The Protocol-relative URL 的 2014 年更新中提出了这个建议。 (原文强调):
Now that SSL is encouraged for everyone and doesn’t have performance concerns, this technique is now an anti-pattern. If the asset you need is available on SSL, then always use the
https://
asset.Allowing the snippet to request over HTTP opens the door for attacks like the recent Github Man-on-the-side attack. It’s always safe to request HTTPS assets even if your site is on HTTP, however the reverse is not true.
More guidance and details in Eric Mills’ guide to CDNs & HTTPS.
如果 Paul Irish 说在 HTTP 页面上请求 HTTPS Assets 没问题,那对我来说就足够了。
关于html - 在 HTTP 页面上通过 HTTPS 加载脚本或其他资源是否有问题?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/20516584/