Resources and tips for deploying HTTPS by default

The fundamental process for deploying HTTPS is straightforward, and there are a wealth of resources online and in print to help you get started. Here's a list of recommended resources to help you understand HTTPS and how to go about deploying it:

That said, deploying HTTPS is often anything but simple in practice. This is especially true for news organizations, because their websites are often large, may have numerous legacy components, and often feature embedded content and advertising from a variety of domains that may or may not be under their control.

As part of developing Secure the News, we interviewed people from several different news organizations that have recently deployed HTTPS. We wanted to know what was easy, what was hard, and what they wish they knew before they started. What follows is a list of potential issues, "gotchas", and recommendations based on these interviews.

Rewriting insecure URLs

Once you've deployed HTTPS, you will have to deal with the fact that both your existing content, as well as the rest of the web, are full of URLs pointing to your old, insecure website (e.g. ""). Fortunately, there are number of things you can do to ensure users are connecting to your new, secure site—no matter where they are coming from.

  1. Redirect users from the HTTP to the HTTPS version of URLs by sending a 301 redirect. Be careful with 302 redirects—they may negatively impact your search engine rankings.
  2. Ultimately, you will need to rewrite your internal links to use HTTPS. The details of how you do this will depend on your Content Management System (CMS), but at a high level this is basically just a giant search and replace.
  3. Consider using Content Security Policy with the upgrade-insecure-requests directive as a stopgap.

Content Delivery Networks (CDNs)

Many large websites are not directly accessible by their end users; instead, their content is delivered through a Content Delivery Network (CDN), such as Akamai, Cloudflare, Amazon Cloudfront, etc. Using a CDN is usually cost-effective for large websites, and allows them to focus on improving the core experience of their web application while leaving the details of scaling content delivery to the CDN. CDNs also typically operate servers around the world, which helps optimize web content delivery for a global audience.

The Washington Post reported that one of their initial hurdles was with their old CDN, which wanted to charge them a significant amount of money to migrate their CDN-delivered content from HTTP to HTTPS, in addition to the increased ongoing cost for using HTTPS on their network. Other news organizations have described similar issues with their CDNs.

We believe these hurdles are caused by CDNs that have an outdated way of thinking about the web, where HTTPS was a luxury commodity that was only required by sites like banks or payment processors. Fortunately, the situation is changing in the CDN market and there are now many CDNs that offer reasonably priced or even free HTTPS content delivery. Talk to your CDN about migrating to HTTPS, and if their terms are prohibitive, consider some of these alternatives:

  • Cloudflare has offered free HTTPS since September 2014.
  • Instart Logic is the Washington Post's new CDN.
  • Akamai has partnered with Let's Encrypt to make getting a certificate cheaper and easier for their customers.

Mixed Content

On the modern web, web pages typically load many subresources—images, audio, video, scripts, etc. Subresources may be loaded from the same or a different origin as that of the site itself; for example, might load an image from (same origin), and embed a YouTube video from (different origin).

For a secure website to be truly secure, both the site itself as well as all of its subresources must be loaded from a secure (HTTPS) origin. Insecure content that is loaded by a secure page is called mixed content. Due to the risks involved, web browsers will either block mixed content entirely, or they will allow it to load but will downgrade the HTTPS lock icon to indicate the potential security risk—the specific response depends on the type of mixed content and the policy of the browser.

Mixed content is often a problem for news organization's websites because they have a preponderance of:

  1. Embedded media (YouTube videos, Instagram photos, tweets, etc.)
  2. Advertising

Mixed content blocking is especially problematic in the context of advertising. Most online advertising today is more complex than a simple image banner ad, and typically relies on embedded iframes, Javascript, or plugin content—both to create more "engaging" advertising, and also for analytics. Unfortunately, these types of (so-called "active") mixed content can be easily exploited to subvert the security of an otherwise secure website, and as a result, are blocked entirely by all major web browsers. This is a significant issue for news publications transitioning to HTTPS, and can impact ad revenue if not handled carefully.

For both embedded media and advertising, the best solution is to fix the problem at the root: work with your content and advertising providers to ensure that their content is available over HTTPS, and use the HTTPS URLs on your site. This is the case today for most major content providers (such as Facebook, Twitter, Instagram, and YouTube) and for many of the big ad networks.

Note that some content providers may provide insecure HTTP embed links by default, but do in fact support HTTPS. We recommend consulting the site's documentation or support if you are unsure. EFF's HTTPS Everywhere Atlas can also be a useful resource.

If you find you have content or advertising partners that do not support HTTPS at all, the best thing to do is contact them and ask them to support it, or considering switching to an alternative provider.

Everyone that we interviewed stressed the importance of working with internal advertising and content teams from the beginning of the transition process to develop protocols for vetting content and assist in communicating with content and advertising partners.

Content Security Policy Report-Only

Unfortunately for many sites, their advertising's "creative" content is controlled by third parties, and can change over the lifetime of a particular campaign or ad buy. In practice, this means that an ad that was verified HTTPS-compliant and approved may suddenly change without warning and stop working due to mixed content blocking.

While this cannot always be prevented, it can be detected, by sending a Content-Security-Policy-Report-Only header and setting up a CSP reporting endpoint. CSP Report-Only enlists your user's browsers to look for violations of a given security policy, and to send detailed reports to the provided endpoint when a policy violation occurs. For example, sending the response header "Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint" will cause your user's browsers to send a violation report to "/endpoint" every time your site attempts to load an insecure resource.

Content-Security-Policy-Report-Only is useful not only for catching misbehaving embedded content, but also for identifying the long tail of insecure sub-resources and links in a large site.

Note that when CSP reporting is deployed at scale, you may find yourself receiving a lot of report traffic. It is also usually desirable to have a dashboard to help you parse incoming reports in real time. There are a number of open source projects that implement CSP reporting endpoints, and we've also heard good things about third party services like and Sentry.


SEO is a tricky topic because the inner workings of large search engines are closely guarded secrets. Google has said that they are now using HTTPS as a positive signal in their site ranking algorithm, although everyone we spoke to said that any boost to their rankings after transitioning to HTTPS was either small or unnoticeable.

Generally, most people that we spoke to said they did not encounter any serious issues with SEO during their transition to HTTPS. One organization, Wired, did report seeing a worrying reduction in SEO rankings after switching some sections of their site over to HTTPS as part of a gradual transition. Their rankings have since recovered. While they were never able to pinpoint the cause of the temporary change, they did write about their experience in detail here.

To avoid similar issues, we recommend monitoring your own analytics and using Google's webmaster tools as you transition your site to HTTPS. We also recommend reading:

  1. Google's guide for transitioning your site to HTTPS.
  2. Search Engine Land's HTTP to HTTPS: An SEO’s guide to securing a website.


Large and long-running websites often have lots of subdomains devoted to different specialized purposes. Some of these subdomains may run on separate infrastructure from the main site, which means additional work may be required to transition them to using HTTPS.

Subdomains are primarily an issue if you are considering deploying HSTS to harden your HTTPS deployment. HSTS has an optional flag, includeSubDomains, which allows you to specify whether or not HTTPS should also be enforced on all of the subdomains of the domain that is serving the HSTS header. Setting includeSubDomains makes your deployment more secure, but it should be deployed carefully—if any of your subdomains do not actually support HTTPS, setting HSTS with includeSubDomains will make those subdomains inaccessible.

Learning from other news organizations

Finally, many of the large news organizations that have recently deployed HTTPS have been admirably transparent about their process and the challenges they faced along the way. Their writeups are worth reading for anybody considering deploying HTTPS at a similar organization:

Wired published a series of articles about their process for deploying HTTPS site-wide: