Is it possible to detect a SSL strip attack by checking whether the page delivered is HTTPS or HTTP using JavaScript? I am assuming that the response page is HTTPS page instead of HTTP?

3 Answers 3


You may want to look into setting your webserver to HSTS (Strict Transport Security) which uses a special response header to tell the browser to only accept https traffic. Full Disclosure: As you might have expected, IE support < 11 I believe is limited. If you must use something client-side to check for https I think you could use window.location.protocol.

  • This helps if the first access to the site is done without sslstrip, otherwise sslstrip could remove the HSTS header. Commented May 22, 2015 at 14:10
  • The HSTS header does not need to be removed. See my comments on the answer here: security.stackexchange.com/a/70934/35267 To prevent attacks during the first access, the owner of the website should include its website into the preloaded HSTS list of the browser (ofc this is only possible if the browser supports this, like for example with firefox and chrome).
    – efie
    Commented May 23, 2015 at 18:10
  • First, HSTS is not even available for a large part of browsers (Internet Explorer). And you really believe that preloaded HSTS is possible for all sites in the world containing sensitive data? I doubt it. Commented May 24, 2015 at 7:59

You might try the following:

  • Create a cookie with Javascript. Set the secure flag on the cookie, so that it is only usable for https connections.
  • Make a https request to the server and check if the secure cookie was received. If it was not received then you can assume that the request on the client side was not done with https, i.e. something like sslstrip was active.
  • You mean that you check at the webserver if the secure cookie was received, right? Maybe my understanding of cookies is incorrect, but what if the user sends a request to the webserver for the first time? It hasn't been instructed yet to send a cookie, so it cannot send a cookie. That means that the webserver would not respond to the request? Furthermore, assuming the sslstrip attack takes place when the user requests the site for the first time, the attacker could modify the "Set-Cookie" header, or the javascript code which should have created the secure cookie, coudn't he?
    – efie
    Commented May 23, 2015 at 12:50
  • Set-Cookie header is to weak, that's why I proposed creating the cookie with Javascript. If you expect an attacker which targets a specific web site and knows up front how the Javascript will look like and how to modify it then you have lost anyway. This protection is more against a broad sslstrip and not a site-specific attack. And you could simply only provide sensitive data on the site if you've got the https-only cookie. It's probably a good thing to combine this idea with HSTS (see the other answer) so you get protection on the client side (if HSTS is supported) and on the server side. Commented May 23, 2015 at 13:15
  • What about my first point? How can the client reach the website at all, if the first attempt does not work (because it cannot send the cookie as he does not have it, thus he won't get a response) and thus the subsequent also won't? Regarding your new statement: I think I see what you mean, but an attacker could connect to the most famous 1000 sites via HTTPS, capture the javascript code used for generating the cookie, and include the site specific javascript code deletion into his broad sslstrip-attack. You could generate unique javascript code each, but this is solution is kind of hacky. 1/2
    – efie
    Commented May 23, 2015 at 18:19
  • For browsers which support HSTS, to prevent sslstrip attacks sending the HSTS header and using the HSTS preloaded list is the way to go. 2/2
    – efie
    Commented May 23, 2015 at 18:24
  • Maybe we understand the question different. For me it is a question of a smaller provider, which wants to make sure that clients can only get access to the sensitive part if the connection is not ssl-stripped. Preloaded HSTS is probably the best way if available (which excludes IE!), but I doubt that it is reachable for a small provider to be included included into all browsers this way. On the other hand it is not inside the most important 1000s sites too, so chances are high that its own script based sslstrip detection will not be specifically evaded by the attacker. Commented May 24, 2015 at 7:58

You can use window.location.protocol to check what protocol is in use. But the attacker can deliver page without this tag, so you will need a check for existence of this script in page. Personally, I would use HSTS for eliminating this type of attack, not by checking the protocol.

You must log in to answer this question.

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