Security Advice

SSL Redirect - Best Practices

Some of my views and practical experiences of SSL redirects, why you might use them, and what kind of redirect to use.

The Problem

When a user goes to a site for the first time, often times its because they typed the name into their browser, or clicked a link in an email from a colleague, or did something else that meant not typing the protocol.

For example, they may type “”.

Browsers, will usually (assuming various assumptions) give you in this case. This means that the user will now be connected to the site, not over SSL, and all their passwords, or whatever else they do, is vulnerable to a man-in-the-middle (MITM) attack and their requests can be scraped.

We want them to use SSL for everything.

The Solution

I have found that the best solution, is to get the web server to perform the redirect before any of your own code. 

Here is an IIS example. What it means is that all traffic being passed over to the application itself will be for HTTPS URI's and you no longer have to concern yourself with the distinction. But it comes with a decision.

		<rule name="HTTP/S to HTTPS Redirect" enabled="true" stopProcessing="true">
			<match url="(.*)" />
			<conditions logicalGrouping="MatchAny">
				<add input="{SERVER_PORT_SECURE}" pattern="^0$" />
			<action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" redirectType="Found" appendQueryString="false"/>

Should you use Permanent (301) or Found (302) ?

In SEO terms, a 301 gives a very slight (google will not tell us exactly how much) ranking bonus.  They recommend that you use a 301 but they don't talk about the potential downsides. There are several possible justifications for this.

  • security. When a user navigates to the http version at a later point, their browser will immediately transform their URI to the https version. This means that a MITM isn't able to hijack their request.
  • performance boost. If google indexes a URI and gets a 301, they can update the link. The user is now able to go right to the new location without a browser redirect.
  • saving money. If google knows that a URI redirects somewhere else, they don't have to redirect their spider, it can go right to the new URI. Your server, and theirs, have to work a little less hard.
  • It's just rumour. Who knows for sure anyway?

Great! Let's use 301 for all the things ever!!!

Hold on. Don't forget, a 301 is permanent - all the reasons above are great, but if your link is an internal nav, you can get stuck.

For example if your application is a blog editor, and you're changing the structure of a url from /blogeditor/{id} to /blogs/edit/{id}, you don't want to get stuck if you later change a feature which means something has moved yet again.

You also have to be fairly sure that you are happy to lose control of that original URI as long as people have it in their browsers.

If you try to change where you're sending the old URI to that won't work for people who have a 301 stored.

If you change your mind and want to go back, you can't put a redirect from the new URI to the old one - that creates an infinite loop.

What about HTTP Strict Transport Security (HSTS)?

HSTS has some nice features - it guarantees that the users's browser, once it sees an HSTS header, will always pre-transform a http URI to an https one. This means that hackers using a MITM attack will (in theory) NEVER see a http/s request, except for the very first time that user's browser hits the domain. HSTS also has a lifetime, so you can say for example that for the next 3 months after the first hit, the browser should always assume HTTPS.

Security focused people will usually recommend this because of the security benefits. If you pay for a penetration test, you will almost always get the advice (typically with medium severity or equivalent) that you should use HSTS. From the perspective of security its great, but HSTS is a double edged sword. It's a way to lose control of an entire domain (including all subdomains) if used incorrectly. Using it without the proper research and training can leave you with some serious problems. To quote an article by cloudflare:

There is one caveat to HSTS: it's a policy cached in each browser. If you configure HSTS settings, browsers will cache those settings for the duration of max-age. We recommend 6 months. If your site becomes inaccessible over strongly-configured HTTPS, web browsers will refuse to connect to the site on HTTP until the policy expires in the browser. Therefore, it's important that you set up HSTS only after establishing a stable SSL configuration.
– Cloudflare -


My advice is as follows:

  • Use SSL for all web applications;
  • Let your web server perform the redirect, so that your application only ever sees HTTPS traffic;
  • Consider HSTS headers, but only once you have fully researched and understood HSTS;
  • If there are SEO considerations, use a 301 for redirects to SSL;
  • For internal redirects (e.g. things behind a login screen which spiders never see and aren't expected to index) use a 302.
An Article by Gavin Burton

As a core member of our development team, Gavin draws on his spectrum of experience in web application development for a variety of industries to play a key role in the build of RDC's innovative products.