如何解决Chrome浏览器自动把src里的http切换为https

in Archives with 0 comment

在以往的Chrome版本中,需要网站管理员在网页返回的header中添加Content-Security-Policy:upgrade-insecure-requests,提醒浏览器强制将页面中的http链接转为https。如果不加这个header,Chrome浏览器在F12调试界面会报错,但不影响网页引用的http资源加载。

但是新版的Chrome已经默认实行强制https策略了,访问网页中src资源时中自动由http转为https,但如果引用的资源无法通过SSL访问,Chrome浏览器会阻断这个资源,就导致了多媒体播放失败,外部JS不执行等等后果。

出于安全因素,Chrome 79和80版本,主要针对多媒体和js资源的混合内容(mixed content)http自动升级https;最新的Chrome 81版本,连img src里的http图片资源都会自动强制转https。

解决方案:

最根本的解决方案是将所有的http资源向https迁移。这也是官方推荐的方案:

Developers should migrate their mixed content to https:// immediately
to avoid warnings and breakage.

另类解决思路:以mp4播放为例,由video标签改为使用iframe调用。

详细信息:

https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html

原文:

Today we’re announcing that Chrome will gradually start ensuring that https:// pages can only load secure https:// subresources. In a series of steps outlined below, we’ll start blocking mixed content (insecure http:// subresources on https:// pages) by default. This change will improve user privacy and security on the web, and present a clearer browser security UX to users.

In the past several years, the web has made great progress in transitioning to HTTPS: Chrome users now spend over 90% of their browsing time on HTTPS on all major platforms. We’re now turning our attention to making sure that HTTPS configurations across the web are secure and up-to-date.

HTTPS pages commonly suffer from a problem called mixed content, where subresources on the page are loaded insecurely over http://. Browsers block many types of mixed content by default, like scripts and iframes, but images, audio, and video are still allowed to load, which threatens users’ privacy and security. For example, an attacker could tamper with a mixed image of a stock chart to mislead investors, or inject a tracking cookie into a mixed resource load. Loading mixed content also leads to a confusing browser security UX, where the page is presented as neither secure nor insecure but somewhere in between.

In a series of steps starting in Chrome 79, Chrome will gradually move to blocking all mixed content by default. To minimize breakage, we will autoupgrade mixed resources to https://, so sites will continue to work if their subresources are already available over https://. Users will be able to enable a setting to opt out of mixed content blocking on particular websites, and below we’ll describe the resources available to developers to help them find and fix mixed content.

Timeline

Instead of blocking all mixed content all at once, we’ll be rolling out this change in a series of steps.

In Chrome 79, releasing to stable channel in December 2019, we’ll introduce a new setting to unblock mixed content on specific sites. This setting will apply to mixed scripts, iframes, and other types of content that Chrome currently blocks by default. Users can toggle this setting by clicking the lock icon on any https:// page and clicking Site Settings. This will replace the shield icon that shows up at the right side of the omnibox for unblocking mixed content in previous versions of desktop Chrome.

In Chrome 80, mixed audio and video resources will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 80 will be released to early release channels in January 2020. Users can unblock affected audio and video resources with the setting described above.

Also in Chrome 80, mixed images will still be allowed to load, but they will cause Chrome to show a “Not Secure” chip in the omnibox. We anticipate that this is a clearer security UI for users and that it will motivate websites to migrate their images to HTTPS. Developers can use the upgrade-insecure-requests or block-all-mixed-content Content Security Policy directives to avoid this warning. Here is the planned treatment:

In Chrome 81, mixed images will be autoupgraded to https://, and Chrome will block them by default if they fail to load over https://. Chrome 81 will be released to early release channels in February 2020.

Comments are closed.