SSL 101: Understanding Asset Loading Within a Secure Environment

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.

✓ 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("success");

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! ☺