Making the Switch to HTTPS

HTTPS (HTTP Secure) has been around for a while, however it’s becoming increasingly important to implement it. Not only does it provide enhanced security, but it’s becoming more common for browsers to prevent access to useful API’s without it. For example without a valid certificate Chrome will block access to the Geolocation and Service Worker API. In addition certain search engines are also starting to favor sites using HTTPS in their site rankings.

Applying a certificate is not usually an overly complicated process. However depending on the type of content your site serves, it might be necessary to make a number of Front-End changes to ensure that the transition goes as smoothly as possible. I recently worked on rolling out HTTPS for Alaska Dispatch News, and in this post I’d like to talk about some of the things we came across in our effort towards getting the shiny green padlock next to our URL.

HTTPS Padlock

Mixed Content

HTTPS is the protocol of which certified pages are served over. Whenever you’re serving a page over HTTP (Unsecure) you’re able to embed and display content from HTTPS pages. For instance at the time of writing this post my blog is not certified, however this YouTube embed which sources from a secure page is:

If it was the other way around, and this site was secure but the embed wasn’t, you’d receive a mixed content warning. The mixed content warning indicates that you’re trying to serve insecure content over a secure connection, and will block it from being displayed entirely.

These errors are going to be inevitable on a blog/news site. Fortunately there are things such as Google Chrome DevTools which helps you spot these problems rather quickly. Within DevTools there is a tab labelled Security which lets you analyze these errors to see what exactly is causing them.

Mixed Content Warning

You’re also able to filter for network content being requested over HTTP using the filter area of the Network tab. The following filter will display all HTTP content being requested by Facebook.

domain:connect.facebook.netscheme:http

Mixed Content

In most cases sites which provide embeddable content such as Instagram, YouTube and Facebook will already support HTTPS. But in some cases we found that some lesser known providers did not. Educating people on the difference between secure and insecure content is important, especially for a site which has hundreds of pieces of content being submitted to it daily. Users expect everything to just work, however the browser does not make it strikingly obvious as to why it doesn’t unless you know how to utilize the developer tools.

Protocol-Relative URL's

In a few instances we had to switch some embed URL’s that linked off-site to their HTTPS counterparts. One of way of doing this is using protocol-relative URL’s to allow the content links on the Front-End to be relative to the protocol of which the page was loaded with. The idea of it is to prevent content from not being displayed if the URL path is set for a insecure domain while yours is secure.

If this jQuery embed was placed on a secure page it would throw an error and prevent it from being loaded:

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

However if you switch it to be protocol-relative, by removing the http: it will serve the correct script regardless weather the user has loaded the page via HTTP or HTTPS.

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js"></script>

Advertisements

No doubt the biggest hurdle of them all, and one of the biggest factors when it came to making the decision to switch to HTTPS was advertisements. Alaska Dispatch News serves its advertisements through one of the most popular ad management systems, DoubleClick for Publishers (DFP). I’m not an expert when it comes to DFP, nor would I ever claim to be, but during my time with Alaska Dispatch News I’ve learned more about it than I would have ever cared to previously.

Advertisements

DFP allows you to serve advertisements from multiple ad exchanges under one banner. The user will make a request to the site, which will then turn to the corresponding ad exchange to serve content in its designated ‘slot’ on the site. There were multiple discussions regarding ad exchanges in the build up to this rollout, and a significant amount of maintenance had to be carried out to ensure that only secure advertisements were being requested from them. Some exchanges don’t support HTTPS at all, however as it is becoming more popular, ad exchanges are being forced to adapt to the new standards. Long-term we are hoping that these changes will make an improvement in the quality of ads from ad exchanges which appear on the page.

Conclusion

Enabling HTTPS should be a priority, not only for the security and SEO benefits but because many of the modern browser tools require it. While this change was several months in the making, the added benefits will certainly make the time invested worth it.

If you have any questions please reach out on Twitter or via the contact form.