HTTPS connection is "not safe" due to images

Question

I am currently working on a website and I have successfully installed my SSL certificate.

The GeoTrust SSL/TLS checker confirmed that the certificate chain (including CA) is properly installed. Everything looks fine on Chrome but my padlock is not green and on Firefox it actually states that the website is not secure because there is unencrypted elements on it.

I used an online service to check why that is and it turns out that indeed my images are not considered secure URLs. How do I deal with this situation, aka how do I embed images on my website securely?

Solution 1

Your image tags must currently look like:

<img src="http://example.com/images/image.jpg">

That http in there means that the image is NOT served securely. An attacker could change the image in transit and thereby change how your otherwise secure page looks to your users.

Instead you could use any of the following to serve the images securely:

• Link to https explicitly: <img src="https://example.com/images/image.jpg">
• Use relative linking to images on your own domain: <img src="/images/image.jpg">
• Use protocol relative linking to use images from other domains: <img src="//example.com/images/image.jpg">

Explicit https will always serve the image securly (even when the page is not served securely) while relative linking will serve the image securely only if the page is served securely.

In Firefox and chrome you can click on the padlock and get more information about the problem. Having done so, here is a screen shot from Firefox showing a list of all the images an the page. It is easy to scan the list and see which ones are http:

Solution 2

The issue is that your page is serving links from a http location as opposed to https. This is due to using absolute http links to reference resources such as images. There are two better methods which will enable you to reference links in either http or https and avoid this issue.

It requires you to find these links and change them either to:

1. relative links: ie. /wp-content/yourtheme/images/image1.jpg
2. or place // at the front of the domain as in //example.com/wp-content/wp-content/yourtheme/images/image1.jpg This will then serve these resources over http or https based on whichever request was made.

In both Chrome and Firefox you can click the padlock icon and then click through to view a list of the offending insecure links. And if you cannot see any images or other resources highlighted in the browser but are still getting errors you may discover that there is a javascript call that is referencing links absolutely via http.

Solution 3

If none of these suggestions help when it comes to inability to display images after you have enabled SSL on your webpage, then check just in case cPanel's settings for Hotlinks, which is under the Security section of the cPanel. It's very possible that in this setting you have the following: http://example.com and http://www.example.com are enabled to allow to access the images while the https version of these are not enabled.

Solution 4

It is really basic. When you are building websites served over SSL (https) any reference in your code that is not prefaced with https will throw up security warnings - other than links. Note that most (all) browsers also default relative links to http. So if you would reference /uploads/12/5/img.jpg or /js/jquery.js the transfer protocol will default to http - which is really annoying.

All browsers handle the warnings a little different but you will get some kind of message. A general statement would be that the new the browser the more severe the message will be. Some older browsers practically ignore these errors while newer browsers can act like your world is under attack because of the missing "s".

View more solutions

Comments

[fNek]

This is not true because: 1) <img src="..."> tags can indeed give this kind of error, if you enter an HTTP url (as opposed to an HTTPS url) and 2) the type of ceritificate or the way it is processed have absolutely nothing to do with this

[Fercho]

I use for img src global media tags like {{media url="path/to/image.jpg"}} with or without ssl protocol and I get no errors. By the way im pointing to Stephen´s Firefox ssl error displayed. Regards.

[fNek]

If you use relative URLs, there are no problems, because they are relative. Please read the other answer. I know that you are referring to Stephen's error. Certificate types still do't have anything to do with it.

[John Dvorak]

"An attacker could change the image in transit and thereby change how your otherwise secure page looks to your users." - or even trigger a vulnerability in the renderer.

[MySky]

"most (all) browsers also default relative links to http" Err, what? Absolutely all browsers, unless they're broken, would use current protocol if you not specify new one explicitly.

[Lightness Races in Orbit]

Oleg is right; that's not "annoying": it's completely wrong.

[Darkhogg]

And hijack cookies, which might include access tokens.

[martijnve]

This is completely wrong. Disregard this answer.

[mti_]

It sounds very much like it is adviced to do so. Thanks to you I have managed to get my green padlock but a friend said that encrypting images might slow down the page. Is this an issue in my case?

[Stephen Ostermiller]

There is certainly some overhead to encryption, however it is usually no more than 10% these days. That performance penalty (even for images) is the price you have to pay for a secure site.

[mirabilos]

// at the beginning is nōn-standard, and browsers such as Lynx will complain.

[blankip]

@martijnve - How is my answer wrong?

[martijnve]

@blankip see oleg V. Volkovs comment. Any reference that does include http is wrong. ALL others are fine. (protocol relative, domain relative, path relative). And you should use relative links in almost all cases anyway.

[Bryan]

The type of certificate has no impact on the so-called 'mixed-content warning'. Also, all modern browsers these days show the warning, some clearly, others simply by refusing to show the Lock icon.

[chokirock]

whynopadlock.com is a handy tool to quickly pinpoint the unsecure resources at a specific URL.

[Stephen Ostermiller]

@mirabilos RFC 1808 is the standard for URLs and specifies protocol relative links (starting with //) in section 2.4.3. The standard is now 15 years old and implemented by all major browsers including Lynx

[garth]

#mirabilos Check your recommended Google repository links. You'll find Google has been using them for many years.