New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 81637 link

Starred by 48 users

Issue metadata

Status: Fixed
Email to this user bounced
Closed: Aug 2011
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Feature

  • Only users with EditIssue permission may comment.

Sign in to add a comment

Block script/CSS/plug-in loads that are over http, and occur within https pages, aka "mixed content errors"

Reported by, May 5 2011

Issue description

This was turned on as of

This bug is filed to track notes and any troubles with this feature.

The feature may be disabled with the new command-line flag --allow-running-insecure-content
Mixed-content images and frames are not blocked by default because of the much higher incidence and much lower risk. That can however be turned on by --no-displaying-insecure-content

Note that the risk of this feature is greatly limited by the fact that IE9 behaves similarly. (IE9 does have a sort of "infobar" to load the site insecurely but I opted not to have an infobar in iteration #1 because users just click through it. It is therefore more secure to not have an infobar at all).

If you find something that is broken by this, this is the bug to note it on (although beware that the correct course is likely to notify the buggy web site).

Showing comments 33 - 132 of 132 Older
What about the discrepancy of results between clicking "Load Anyway" and disabling the insecure-content flag? For example, when I had the --no-displaying-insecure-content flag enabled and clicked "Load Anyway" the omnibar continued to display a secure-green https, yet I was expecting that the "yield sign" would appear over the https. Was it indeed still secure or this is a bug? The reason I ask is because when the insecure-content flag is disabled then the Omnibar shows the "yield sign" over the https when I click the star. "Load Anyway" basically reloads the page with the setting changed to "allow" instead of "block".
The star image isn't loaded automatically on page load, so you won't see the yield triangle util you click the star again.
Issue 72015 has been merged into this issue.
@bernhard.bermeitinger: thanks! Yep, I was looking at this one yesterday. I'll get it nailed down ASAP.
I understand the use of this function, but there should be a way to disable it via advanced settings without having to add a command line parameter.
The "Learn more..." link in the infobar should open a new tab and not navigate away from the mixed content page.

Comment 42 by, Jun 24 2011

Now (I'm on r90349) both of the buttons read "Load Anyway". Try a Wikipedia page, for example, to see this.
As it turns out, we intended to revert to a one-button design - but it looks like there is a missing GetButtons virtual method in that would have said "one button".

Comment 44 by, Jun 26 2011

The VM ticket/customer support system is unusable because of mixed content. Sending a ticket takes the user to a page that has mixed content and does not send the data. Then reloading breaks the flow and causes the form to error.
@adys.wh: thanks for taking the time to report! I've also had a complaint about a problem trying to book a plane ticket on Virgin America... maybe it's the same issue?
It sounds like something Virgin really want to fix, on account of being a security bug and also the possibility of losing money. I'll try and find a contact.

Comment 46 by, Jun 28 2011


Comment 47 by, Jun 28 2011

Ran into this problem with the Google Plus signup

Comment 48 by, Jun 28 2011

jonnew: thank you for reporting the issue with the the Plus signup page. This has now been fixed. still exhibits problems -- once you login, the site basically displays nothing until you "run insecure script".
@pkasting: I don't use that site; any chance you'd be willing to fire them off an e-mail explaining the error of their ways? Also, if you had IE9 around, could you see if there's a similar behaviour there?
You can log into it with your GAIA account, you don't need anything site-specific.

The same problems occur with IE9.

I don't know enough to send anyone a useful mail.  AFAIK this site is run in conjunction with the Google transportation team so it seems like there ought to be someone internal concerned about it.
[Minor] Google logo ( is served over HTTP for the following HTTPS pages causing mixed content warnings to appear:

I reached these pages by clicking the "I'm Feeling Lucky" button on

Comment 53 by, Jul 25 2011

Oddly nobody mentioned this yet, but any http-included script (eg. youtube videos) in rss feeds causes a mixed scripting error on Google Reader over https.

Comment 55 by, Jul 25 2011

I'll fix the image URL on the logos pages. Reader will hopefully be fixed in the coming weeks. Finally, we're aware that pages need significant amounts of work.
[Minor] Several instances of images served over http for these https pages: (user images --

Rather than clutter this page up with comments like these, is there a better place to report such occurrences?

Comment 57 by, Jul 28 2011

Labels: -Mstone-14 Mstone-15 MovedFrom-14
Punting out non-critical bugs.  Please move back to 14 if you believe this was done in error.
Status: Fixed
We're done with this for now:

M14: blocks mixed scripting with an infobar on * Also has flag --no-running-insecure-content

M15: blocks mixes scripting with an infobar on *. Also has flag --always-run-insecure-content

It's not clear if we can promote this feature to * for M15, but it's worth trying.
I've noticed none of the sites Chrome shows as having insecure content/scrips show as insecure in Firefox if the AdBlock Plus add-on is enabled in Firefox. NoScript will sometimes defeat insecure content/scripts as well even when the "Scripts Globally Allowed" setting is enabled (i.e., the NoScript add-on is enabled but all scripts are nevertheless allowed to run).

I installed the AdBlock Plus add-on in Chrome with the same filters as I was using in Firefox, but it does not block insecure content/scripts like it does in Firefox. 

I have replicated this on many sites; however, is a good site for testing it. In Chrome, the MAIL tab sometimes shows insecure content while the USER LAB tab shows secure. Other times both the MAIL and USER LAB tabs will show insecure scripts in Chrome. But in Firefox when AdBlock Plus is enabled, both MAIL and USER LAB tabs always show secure. 
This bug is not about AdBlock Plus, Firefox, or any other extensions or browsers.  Given the number of comments here it's important not to go off on tangents.
This feature prevents the display of AdSense ads on a page delivered over https. To my knowledge AdSense doesn't provide an https version of their scripts, so this feature will cause the insecure content warning to appear on any https page that includes AdSense ads, and I'm sure the same would be true of other ad networks as well.

I ran across the issue in a Facebook game I am developing. Starting on October 1, Facebook is requiring all Facebook applications be served over https (see,  so developers of ad-supported games and apps (and by extension AdSense) are going to find that Chrome users aren't seeing the ads they've included to monetize their content.
@brian: thanks for the note.
Can you paste the HTML fragment you use to include AdSense ads in your app? I'll see if there's a working HTTPS equivalent.
Also, don't you hit this issue already in IE9 ?
Sure thing. Here's an example AdSense snippet:

 <script type="text/javascript"><!--
                google_ad_client = "ca-pub-2880202210813851";
                /* StatusFightBelowStatus */
                google_ad_slot = "4138342926";
                google_ad_width = 200;
                google_ad_height = 200;
<script type="text/javascript"

Comment 65 by Deleted ...@, Sep 23 2011

I get "This page has insecure content" warnings when visiting a variety of Google websites. Is just me, or should Google be the first to acknowledge the mixed scripts considering their browser is giving invasive warnings that persist despite turning it off on the command line.

//Rant over

Comment 66 Deleted

@evan: It would be helpful if you could provide the exact URL to us when you hit this on one of Google's websites.   Also, which version of chrome are you running, and what it your exact command line that fails to disable the warning?

Comment 69 by, Sep 23 2011

Google finance comes from doubleclick. The google code issues should be reported at Youtube issue is known afaik.

Comment 70 by, Sep 24 2011

Firefox implements a similar policy, so my question is why doesn't Chrome listen to the X-Content-Security-Policy header?

It really is not a good idea to require that everything be SSL on a page, especially images if you just specify where things are allowed to come from (and what things can be done, like inline scripts and eval), which is what the header is for.

And nobody wants to click (especially if they don't understand what's going on) 'Load Anyway' over and over again. The flag is a workaround for DEVELOPERS, nobody (especially on a Mac) is going to even consider trying it.
> Why doesn't Chrome listen to the X-Content-Security-Policy header?

Content-Security-Policy is still going through the standards process.  Chrome listens to the X-WebKit-CSP name.  Ideally Firefox would have picked a vendor prefixed name for their implementation prior to standardization as well.  Once the standard is done, we'll all listen to Content-Security-Policy.

Comment 72 by, Sep 25 2011

I am having lots of trouble finding documentation on these headers and I do not want to use meta tags to do this.

The W3C information is clearly not up-to-date (and not complete) and it doesn't seem to even mention about 'allow' directive.

I placed X-WebKit-CSP header in Nginx with the same options as Firefox (which works 99% other than some error in the log which doesn't seem to matter). This paranoia mode that the browser is running in is very frustrating to deal with. All I want is to allow content from the same domain (don't care about subdomain), and for the moment, with certain packages like MantisBT, I have to allow inline scripts (say poor programming on their part all you want, but that's how it is now).

From configuration:
add_header X-Content-Security-Policy "allow 'self'; img-src http://$server_name https://$server_name; style-src http://$server_name https://$server_name; options inline-script"; # Works mostly
add_header X-WebKit-CSP "allow 'self'; img-src http://$server_name https://$server_name; style-src http://$server_name https://$server_name; options inline-script";
@audvare: This isn't the right bug to discuss these issues.  This bug is about mixed content detection, not Content-Security-Policy.

The documentation of CSP should improve as the specification moves further along the standards process.  In the meantime, this is the most recent draft of the specification:

Comment 74 by, Sep 25 2011

Apparently, Chrome (latest available on site) and Chromium (14.0.835.162) listen to  X-Content-Security-Policy, not the old one.

Comment 75 by, Sep 26 2011

Tesco online shop has a few issues too on [evangelism] (might need an acc)

Comment 76 by Deleted ...@, Oct 5 2011

Warning for

Unsafe JavaScript attempt to access frame with URL from frame with URL!id-replace here/d=1/. Domains, protocols and ports must match.

Comment 77 by, Oct 26 2011 mixed content errors on domain

Also some adsense one reported in  issue 101334 

Comment 78 by, Nov 25 2011

The default behaviour totally breaks any bookmarklets that dynamically load a script from http into the current https page.  Moreover, since they are bookmarklets and can only run in the currently visible content, clicking the infobar's "load anyway" button causes a page reload, making that bookmarklet useless.

Comment 79 by, Nov 25 2011

I should clarify:  re-running the bookmarklet after the reload does work.  Maybe that's the best we can get, without having to modify a bookmarklet to load from https.
@paxunix: thanks for the comment, and an interesting use case. The dynamic loading of an http script into an https page does represent an unpleasant security vulnerability (i.e. the total loss of HTTPS), so if the script can be fetched over https, that would be first preference.
I won't complain about the default settings.
But when I land in a "not really secure" site with mixed content, with the appropriate warning icon, I should be able to ask to reload the page without this content (without restarting Chrome with a --no-displaying-insecure-content option I should take back afterward).
Is there a way to do so ? IE does this with a popup or infobar letting the user choose. But it is fine to let load insecure content (display, not script), and in the https information under the warning icon, have a button allowing to reload safely (though maybe a bit broken).
Else I am stuck in a login page not beeing able to log in really securely...

last page I encountered the problem :
Could you report that to whoever owns ? Telling us (chromium developers) about an error on some website out there doesn't help anyone.

Comment 84 by, Jan 24 2012

That would be the EFF. But openlayers is the one who should be contacted, they don't provide an https alternative and their api is supposed to be public.

BTW, I'm reporting here because a chromium dev asked to report insecure content errors here; if that's changed I'm happy to stop.

Comment 85 by, Jan 24 2012

adys.wh: That request only applied towards Google properties, to ensure that things were properly reported internally (which your feedback has been appreciated.

To echo what James has said, it would be best to directly contact the owner/operator of the site in question.

I'll ping EFF.

Comment 87 by, Jan 25 2012 is causing trouble too (It's the example site in google sites -> business template)

Comment 88 by, Jan 25 2012

Nevermind, doesn't seem to be affiliated with Google, but quite a few templates seem to be causing trouble. Is it fixable by the Sites team?
I believe this happens when it attempts to load adsense ads (http) on any
google site (https). It's been an issue for months now that someone really
needs to resolve...

Comment 90 by, Jan 25 2012

Thanks for the heads up. We're aware of the unfortunate interaction between AdSense and Sites and are working to address it.

Comment 91 by, Jan 31 2012 triggers it.

Though the page looks outdated, adsense for video is much better and doesnt trigger it:

Comment 93 by, Apr 18 2012

adys.wh: thanks for the report. Can you tell us what you did to trigger that? It doesn't trigger for me and, if it's something simple like "do a search", then you're probably seeing an experiment that I'm not.

Comment 94 by, Apr 18 2012

It's simply on the page. I'm logged in and have a delegated account in my account list, from the UK, no special preferences afaik.

Logged out in incognito I see it too.

Comment 95 by, Apr 18 2012

adys.wh: thanks for the notice. We're fixing the issue ASAP.

Comment 97 by, Apr 25 2012

adys.wh: thanks, I'll chase that up.
I'm seeing "This page has insecure content" on (which I assume is the yt video)

Comment 99 by Deleted ...@, Aug 7 2012

Just trying to understand if something was done to enable users to accept unsecured content on a secured website. Just blocking unsecured css files makes Chrome inferior to any other browser out there right now. 
yuval: The old infobar has been replaced with a shield icon in the URL bar in chrome 21.0.1180.57.
"Just blocking unsecured css files makes Chrome inferior to any other browser out there right now." -- isn't it quite the opposite? Chrome seems to now have a leading security story here but you can still run the CSS if you really want to, via the new shield icon as noted by adys.wh in comment 100.

If there are any web sites which are very broken and rely on "mixed CSS" to work properly, please list them on this bug. We can reach out and get the website owner to fix their security vulnerability.
Here's a good reference in case anyone else ends up here:

A lot of websites' https setup is broken like that. If you run the https everywhere extension, you'll see exactly just how many. To name a few popular ones:,,
@adys.wh: interesting! Presumably no-one links to the https versions of those sites, otherwise they'd be widely broken in other browsers too? (IE9 comes to mind, and Firefox also has plans to catch up in this area IIRC)
1. Looks like Android Chrome app does not block mixed content (? for
example, I tested on
And it is even more difficult for an user, on a phone, to check the source,
the certificates...

2. On the desktop, the shield message is not very clear (in french : "Cette
page pr

Does Chrome gather any data itself on websites affected by mixed content? If not it probably should.

Many corporate intranet sites are misconfigured in this fashion.  I doubt those companies would appreciate having data about their internal URLs collected in this fashion.

Chrome has an opt-in for "generic collection of data" at installation time. Plus, it would obviously ignore any internal urls (without tld, or even not .com/net/org/cctld). it was just a thought
I can't use the Private Gadget Editor or Domain Gadget Directory from Chrome 21 because those Google developed gadgets refer to a non-https javascript file.  The gadgets themselves are available via https.  If Google is blocking this, then they need to make sure their stuff is in order first.

Also, I am seeing no shield prompt in the Omnibar.  Now I have to use the --allow-running-insecure-content or use a different browser.
Some sites (such as those that opt into HSTS, or those that we whitelist (eg. are held to a higher standard, for which no bypass is provided.  Please provide the URLs of the non-compliant pages and we'll suitably flog them.
@russell.milliner: thanks for the note, but you seem to have omitted the faulty URLs that we would need to follow up and get this promptly looked into and fixed.

Comment 112 Deleted

There's something more to this issue. On a simple https:// login form on a website of ours (private url, sorry), we have this html snippet:

<link rel="stylesheet" type="text/css" href="/static/main.css" />

When I mouse over the links, I see they point to https://.../static/main.css, which is correct. But when I click on the links, I get a (presumably cached) non-secure version, and the url bar shows: http://.../static/main.css. I'm seeing this problem in google chrome v21. 

Is it possible that the caching system is broken wrt honoring protocol? I've seen this exact situation on a number of our sites.

This bug is closed and won't be monitored, so it's best to file a new bug with a repro case we can diagnose. However, first you should verify that what's happening is not actually a server-side redirect from HTTPS to an HTTP URL (which is the more likely situation).

Comment 115 by Deleted ...@, Oct 2 2012

Chrome is not displaying unsecure content without any kind of warning or way to override. This makes life very difficult for me.
dloverde, you'd have to provide us with a specific URL for us to take any action.
dloverde, check the "Shield" icon in the Omnibox/Location bar. It's in the right-hand side. Clicking on it will show an option allowing you to load the unsafe code.

Comment 118 by Deleted ...@, Nov 2 2012

I need to be able to "Enable Display Mixed Content" on Google Chrome.  A site that we must use at work has to have the Mixed Content enabled, or it won't work.  I was able to enable the mixed content on IE, but I don't really care for IE, and our workplace as a whole is migrating to Gmail and other Google Chrome features, but if I need to run this particular program, I'll have to open IE, log into the particular site and run it from there.  I'd rather just stay with Google Chrome, but you leave me no choice.
I have coworkers who must either use Firefox or use google chrome and click the shield icon literally hundreds of times a day. There really needs to be a config setting for "allowed domains for mixed content".

Although not recommended, you can also use the command line flag --allow-running-insecure-content to prevent Chrome from checking for insecure content. Instructions on how to add a command line flag can be found on our Chromium site (English only).
Indeed, the content settings screen would be a great place to manage 
such exceptions, but it does not appear to be there, at least in version 
22 on ubuntu linux. Adding a cookie and site data exception does not 
seem to have any effect. Am I missing something obvious?

Comment 122 by, Nov 17 2012

Videos at Coursera appear to be blocked because of this issue.
Version 22.0.1229.94 Ubuntu 12.10 (161065)
Works fine in Firefox.

Java script console and the security padlock (before location) duly show that this is a mixed content page, although these are not sufficiently obvious when the user is faced with a blank page. 

Suggested actions: Alert on mixed content; allow override by source domain or URL prefix.

@122: Have you pointed out the issue to Coursera? They need to know about this problem.
Also, is there any reason that insecure content shouldn't be loaded if it is already cached in the browser? That would probably mitigate the problem greatly.
I don't follow.  There's no reason to believe the content was legitimate at the time it was first cached, so why would subsequent use be legitimate?

Comment 126 by, Nov 20 2012

@123: Yep, I told Coursera. They haven't replied yet.  I also gave them the link to this issue.   (#123)
Add this to the list of references now silently blocked by Chrome:
type="text/javascript" src="" which is referenced in https sites.

How arrogant can Chrome get? They won't even admit they screwed up on this. When they write the book on Google/Chrome the subtitle will be something like "How Arrogance Destroyed the Empire"

Comment 128 by, Jan 30 2013 is served just fine. Whatever site has src="http://..." should change it to src="//...". Chrome's behaviour is correct there.
Project Member

Comment 129 by, Mar 10 2013

Labels: -Area-Internals -Feature-Security -Mstone-15 Cr-Security Cr-Internals M-15

Comment 130 by Deleted ...@, Oct 9 2013

I appreciate googles intent.  However so much educational media is affected that this is a serious eye-sore for me.  Would google consider allowing people to manage exceptions similar to other things (such as when to allow java) so at least if we have a subset of sites we regularly use we don't have to finght this issue daily.
Given that firefox is moving to the same model, those sites will have to just fix those errors at some point...
Labels: Restrict-AddIssueComment-EditIssue
Yes, the sites are simply broken. Closing comments because the bug is fixed and the behavior is correct.
Showing comments 33 - 132 of 132 Older

Sign in to add a comment