Our web app home page redirects from HTTP to HTTPS. Our security consultant has told us this is a significant security weakness, that the redirect could be intercepted e.g. by SSLStrip. And therefore, we should remove the redirect, and disable HTTP entirely, requiring the user to manually type in https://...

Having studied the issue myself, it seems to me that the initial http response can be MITM faked by an attacker directly - no need for a redirect. So, removing the redirect achieves nothing.

I'm not sure though, if SSLStrip itself specifically can do this - maybe it needs to see the initial HTTP response first.

I understand that HSTS would prevent this problem, IF the device/browser in question has contacted our app once before. But for the initial contact, the HTTP request can be hijacked, regardless of what the app does - there is no protection, unless our web app were popular enough to be included in browser HSTS lists.

What did I miss? Is the redirect from HTTP to HTTPS significant?

I'm loathe to remove it as it will prevent many typical users from being able to connect to our site, and it doesn't seem to achieve anything.

  • Make sure your CEO knows his name when your traffic drops 90% . Don't forget the A in CIA Commented Feb 5, 2016 at 19:25

1 Answer 1


Yes, in a MITM scenario, an initial HTTP request is all it takes to successfully attack (if the user doesn't notice the missing HTTPS). And the only way to prevent this initial HTTP request is HTTP Strict Transport Security (HSTS).

As you know, HSTS means that your server's HTTPS responses include a HSTS header telling the browser only to use HTTPS, i.e. the client doesn't know that he must only contact the server via HTTPS before he gets the first HTTPS response.

But there is a feature of HSTS that solves this problem: preloading! All browsers supporting HSTS, also include a hardcoded list of domains, that must only be contacted via HTTPS. Everybody can submit their domain to be included in the HSTS preload list if they meet the criteria:

  1. Have a valid certificate.
  2. Redirect all HTTP traffic to HTTPS—i.e. be HTTPS only.
  3. Serve all subdomains over HTTPS, specifically including the www subdomain if a DNS record for that subdomain exists.
  4. Serve an HSTS header on the base domain for HTTPS requests:
    • Expiry must be at least eighteen weeks (10886400 seconds).
    • The includeSubdomains token must be specified.
    • The preload token must be specified.
    • If you are serving an additional redirect from your HTTPS site, that redirect must still have the HSTS header (not the page it redirects to).

Disabling HTTP on your server doesn't improve your security: the user won't know it is disabled before his first request and therefore will still make his request via HTTP and allow the MITM to respond to the request – even if your server wouldn't have answered it.

  • Very helpful to have the links to the HSTS preload list. I wonder how scalable that mechanism is though, it's gonna have millions of entries after a while!
    – O'Rooney
    Commented Feb 8, 2016 at 21:04
  • 1
    @O'Rooney yes, it doesn't really scale… But includeSubdomains is a big obstacle for preloading, because it only accepts second-level domains and not many companies are willing to enable HSTS for all of their subdomains
    – Beat
    Commented Feb 8, 2016 at 21:29
  • "Disabling HTTP on your server doesn't improve your security", I can think of cases where it does. Say you implement a password reset email, but accidentally implement it with an http instead of https link. If the servers gladly redirect, this error goes unnoticed that requests are being sent in plaintext before being redirected. So disabling HTTP has the (very) marginal benefit that you aren't accidentally using HTTP links anywhere
    – Cruncher
    Commented Aug 7, 2020 at 15:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .