Blog

I've been seeing an increase in requests for recommendations on adding the protection of HTTPS to client sites. Questions of cost and overall need are the most common.

The standard response to this for years has been yes, if your users are sending sensitive data to your website. Data like credit card numbers, personally identifiable information such as Social Security, or confidential content like financial statements or payroll all qualify as sensitive. 

 

But, I would argue that there is almost always sensitive data being passed between your website and the end user. Even if your typical users are anonymous, your content creators and administrators are not. Maybe an interception of your admin credentials won’t endanger your users’ data but, at a minimum, it would allow a malicious intruder to deface or alter your content.

 

Beyond man in the middle (MIMA) attacks that intercept credentials or other data, attackers can inject their own content in an attempt to generate ad revenue or to fool users into clicking malicious links in their connection is not encrypted. 

 

Then there are the more general privacy concerns. Advertising technology has advanced to the point where our browsing activity, even anonymous browsing activity, is gathered into massive anonymous profiles linked by key identifiers. It only takes one piece of identifiable information to be discovered to link that profile to a real person. Not having HTTPs on a site that allows users’ to sign up for a newsletter can be enough to put a name to a profile that’s been quietly building for years.

 

I'll go out on a limb and assume that the search ranking of your site is a concern to you. Well, Google has been giving a very small ranking boost to HTTPs-enabled sites for years. The effect is miniscule from what I've read but it is still considered a good practice as part of a larger strategy and the impact is likely to increase as time goes on. In fact, the word is that this year Google will take this encouragement a step further. Instead of just marking protected sites with a padlock and the word secure and leaving it off the others, Google is planning to explicitly mark HTTP sites as “Not secure,” even including the red triangle that they currently reserve for sites that have misconfigured HTTPS. 

 

SEO warning: There have been numerous reports of websites seeing a temporary drop in their ranking after enabling HTTPS. This is due to the fact that Google will treat the change to HTTPS as a site move with URL change. There are a number of moves you must make to minimize this impact, starting with adding the new HTTPS URL to Search Console. Follow the Google site move FAQs and all will return to normal in time. The configuration details vary depending on your hosting and the applications you’re securing. Post a comment below if you need a hand with a specific combination. 

 

If blazingly fast mobile page speed with Accelerated Mobile Pages (AMP) or progressive web app (PWA) development are emerging as a high priority for your team then HTTPS should be as well. If you’ve been working with AMP without HTTPs, you’ve likely already seen some issues. A quick scan of the validation errors page (https://www.ampproject.org/docs/reference/validation_errors) yields:

 

“IMPORTANT: Many URL values in AMP require HTTPS. If you are getting this error, and aren't sure why, check the relevant AMP tag's specification to see if the attribute requires HTTPS.”

 

And HTTPS is a requirement end-to-end for PWAs. Given that a PWA’s functionality delves much deeper into the end user’s device, it just makes sense. Sharing media, data, and location information shouldn’t be done on an open line.

 

At the end of the day, there is a single reason that tops all of the others. Switching to HTTPS protects your users’ trust. Whether they realize the full implications of your site having that little padlock symbol in their browser or not, you remove the opportunity for the question to even arise. For this reason alone, we believe so strongly in supporting the adoption of HTTPS that we’ve made it a standard inclusion in new web projects.

Costs for the SSL certificate required range greatly depending on the type of certificate your use case requires but the trust it builds is priceless. Not to mention, the cost you save by not dealing with an incident. Still, it is worth noting that I've seen SSL certificates pricing range from $5 to $1500 per year. And again, depending on your needs, installing and configuring the certificates can represent a substantial effort. 

 

Great news for some use cases: the variety of options have been proliferating in recent years, such as the Commodo PositiveSSL that has a base package at $15/3 years. Or, check out Let’s Encrypt, a Linux Foundation Collaborative Project. They are pursuing their mission to “create a more secure and privacy-respecting Web” by providing free SSL certificates to anyone that owns a domain. Many hosting providers offer SSL as a small addon as well. 

 

A guard against MIMA