I have an HTTPS website which links to images from a CDN, as well as user-generated image links that are not HTTPS.

I get errors like this in console:

The page at https://example.com displayed insecure content from http://www.google.com/images/srpr/logo3w.png.

Does it matter? Should I try to fix this? Is it worth worrying about?

  • Please don't re-post the same question on two StackExchange sites. There are already votes to move the question here from SO.
    – Bruno
    May 28, 2012 at 16:38

3 Answers 3


Yes it is something you should worry about. Most people will get a big scary warning from their browser that your page is insecure, this will scare away most people from staying on your site. Just automatically make all http links https on your website and the warnings will go away.

  • Just automatically make all http links https on your website and the warnings will go away. How is that possible? Someone will eventually make a http link if not everything comes from my server?
    – Charuru
    May 26, 2012 at 10:40
  • @Charuru: Yes, if you let your users include inline images from other sites (with HTTP URLs), you're going to have to do something like proxy those requests through your server. In fact, you may want to do that for all user-supplied external images, even those already using HTTPS URLs, since having images loaded from other sites on your pages would allow anyone with access to the logs of those sites to track your users. May 26, 2012 at 17:17
  • @Charuru - This is even further recommended because you can cache and compress the images on your server so they load faster for your users as well.
    – ionFish
    May 27, 2012 at 2:07

Yes, it matters. When you have content served over plain HTTP in an HTTPS page, the user can't know what's secure and what's not on the page. Therefore, the security of the page can't be ensured.

Never tell your users to turn off these warnings or to ignore them.

See OWASP rule "Do Not Mix TLS and Non-TLS Content":

A page that is available over TLS must be comprised completely of content which is transmitted over TLS. The page must not contain any content that is transmitted over unencrypted HTTP. This includes content from unrelated third party sites.

An attacker could intercept any of the data transmitted over the unencrypted HTTP and inject malicious content into the user's page. This malicious content would be included in the page even if the overall page is served over TLS. In addition, an attacker could steal the user's session cookie that is transmitted with any non-TLS requests. This is possible if the cookie's 'secure' flag is not set. See the rule 'Use "Secure" Cookie Flag'


To elaborate on this, checking that the website uses HTTPS is ultimately the sole responsibility of the user. They must expect HTTPS to be used, and used correctly, otherwise a MITM attacker could downgrade the connection to plain HTTP. (This is why automatic redirections from http:// to https:// are only partly useful; pre-loaded lists of HSTS sites can help.)

To make sure that the content they see is rendered from what the server sent, users must check that HTTPS is used, with the site they intended to visit and never ignore SSL/TLS warnings. This is a GUI problem.

Tolerating mixed content on a page makes it virtually impossible to check what was served over HTTPS and what wasn't. Even developers can struggle to find which resources are loaded over SSL/TLS and which ones aren't.

Resources loaded without HTTPS could have been changed to alter the page (different image, script that performs a different action, ...). In addition, in some cases, session cookies that should only be used in HTTPS will also be used over plain HTTP, allowing the attacker to steal the session (see OSWAP rules).

If you want to use HTTPS, make sure that (a) the user expects HTTPS to be used (that's not really a technical problem) and (b) all resources on the page also use HTTPS.

  • Facebook loads non-https images, although the connection to the site claims that it's https.
    – Nowayz
    May 25, 2012 at 14:23
  • I'm not sure which specific Facebook example you have in mind, but plenty of websites do the wrong thing. Why would you think Facebook gets it right?
    – Bruno
    May 25, 2012 at 14:25
  • @Nowayz: all the images I get through https://www.facebook.com/ are served over HTTPS. What was your point?
    – Bruno
    May 25, 2012 at 20:54

That is more a warning than anything else; just alerting you that not all traffic is secured.

If you're really worried about it you can just proxy those images I suppose... This would be at the expense of your bandwidth though.

The only big thing you would really need to worry about is the end-user misunderstanding something, but assuming you're getting those errors in a developer console, it shouldn't matter.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.