Problem
When visitors to your web site request a page using a secure https:// connection, a broken padlock icon may appear in the web browser's location bar. Additionally, they may receive a warning message:
- Mozilla Firefox displays:
“The connection to this website is not fully secure because it contains unencrypted elements (such as images).” - Microsoft Internet Explorer displays:
“Do you want to view only the webpage content that was delivered securely?
This webpage contains content that will not be delivered using a secure HTTPS connection, which could compromise the security of the entire webpage.” - Google Chrome displays:
“Your connection to example.com is encrypted with 256-bit encryption. However, this page includes other resources which are not secure. These resources can be viewed by others while in transit, and can be modified by an attacker to change the look of the page.”
Resolution
This problem occurs if a web page contains hyperlinks to insecure elements. For example, consider a web page that contains the following HTML snippet:
<a href="http://www.example.com/images/picture.jpg">View my picture</a>
In this HTML snippet, the hyperlink references a non-secure http:// resource (a .jpg file). If a user requests this page using an https:// connection, the page itself is encrypted, but the hyperlinked image file is not. As a result, the page contains secure and insecure content, and the browser displays a warning message to the user.
This problem can occur with any type of hyperlinked resource file - a JavaScript library, a CSS file, and so on.
To resolve this problem, use either of the following methods.
Method #1: Use relative links
You can use relative links in hyperlink URLs to prevent browsers from displaying warning messages about insecure content. For example, we could rewrite the above HTML snippet as follows:
<a href="/images/picture.jpg">My picture</a>
Because the image file is referenced by a relative link instead of the explicitly insecure http://URL as above, the browser does not warn users about mixed secure and insecure content.
Method #2: Redirect all requests to SSL connections
An alternative method is to redirect all user requests to SSL connections. Using this method, even if a user specifies a non-secure URL like http://example.com/page.html, they are automatically redirected to https://example.com/page.html.
