SSL 101: Understanding asset loading within a secure environment

In my experience, I have found that there is generally a lot of confusion surrounding the loading of assets within a web page that exists within a secure environment. To help eliminate that confusion, here is a small guide that will hopefully explain which elements are and are not affected by SSL. It really comes down to two things: Outbound and Inbound.

Outbound

Outbound refers to any hyperlinks or form posts that leave the page.

The following is a non-secure hyperlink to http://archive.tmp.com. The secure environment that this link renders within (the page you are now reading - look in the address bar) has no bearing on it. Outbound links will work as they always have. There is no need to alter them programatically. In fact, the web is built on hyperlinks, so it would be silly to even suggest to our clients that they set up a secure environment to link to or only allow them to link to other secure pages.

http://archive.tmp.com

✓ Solution

Do nothing!


Inbound

Inbound refers to any asset that is pulled into and contributes to the rendering of that page. A couple of inbound examples include:

Images

The following image (that is one crazy looking contraption) is loaded in from a non-secure environment (http://archive.tmp.com/images/content-our-work-overview.jpg)

It will likely load for you (this is considered passive mixed content), however, all browsers will complain about it in some form or another (some more obnoxiously than others, I might add) and user can still block this if they wish. Examples:

Chrome

In console, you will also see the following warning:

The page at “https://dl.dropboxusercontent.com/u/58819/ui-tmp-com/web/articles/ssl-101.html” was loaded over HTTPS, but displayed insecure content from “http://archive.tmp.com/images/content-our-work-overview.jpg”: this content should also be loaded over HTTPS.

Internet Explorer (Older)

✓ Solution

If your assets are hosted within a secure location, use https as a default. Protocol-relative URLs may also be acceptable.


Scripts

Let’s try loading a third-party script library, such as jQuery, from a non-secure location.

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js"></script>

We’ll also write a simple selector that will change the color of the text below from red to green.

$("#script-test").addClass("make-green");

I ♥ web standards!

In many browsers, the text, "I ♥ web standards!", will remain red. This means that the script library has not loaded. The security policies that revolve around scripting within a secure page (and several other elemets - see list below) may be much more stringent. Scripts from a non-secure location will simply not load, and your script based functionality will fail. Sometimes siliently, as was the case with Advanced Job Search from within Facebook Job Search (Ajax requests must also come from a secure location).

Indeed, here is the error being thrown in Chrome's console:

[blocked] The page at "https://dl.dropboxusercontent.com/u/58819/ui-tmp-com/web/articles/ssl-101.html" was loaded over HTTPS, but ran insecure content from "http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js": this content should also be loaded over HTTPS.

Other Elements

The following elements may also fail to pull in or throw warnings on non-secure assets, media and/or external pages:

  • audio
  • embed
  • frameset
  • iframe
  • link
  • object
  • source
  • video

✓ Solution

Use protocol-relative URLs or https as a default in these cases.

Update! Paul no longer recommends this method. If you know that the server you are pointing to has SSL, then always point to https.

Note: Pages that you would like to pull into an iframe could very well have extra measures applied to them by their server administrators. See X-Frame-Options response header for more information. The same goes for other cross-site server requests. See HTTP Access Control (CORS).

So, there you go! It's not that hard to wrap your head around it when you come at it like that! Hope this helps! ☺

About the Author

Michael Spellacy

I am Michael "Spell" Spellacy, Director of User Interface Design and Development at TMP Worldwide. If you have any questions, feel free to contact me on Github or follow me on Twitter.

Moderators

Contributors

If you wish to contribute, fork this project, make some changes, and create a pull request.

New to GitHub? Learn the basics with the guide and learn the GitHub flow.

Quality Assurance and Accessibility

All patterns, layouts, and functionality are tested against our supported browsers. We also look for accessibility issues via automated and manual testing tools. TMP is committed to the accessibility of its websites and products and strives to meet as much of WCAG 2.0 Level AA as possible. If you discover any problems with our work, please open up an issue and let us know about it or contact Michael Spellacy.

Return to top