Google Chrome is probably one of the stricter browsers out there in terms of highlighting SSL errors.

Most browsers will point out when you are viewing an HTTPS page which loads insecure images/Javascript, I understand how this is a security issue - an attacker could have modified the non-SSL content in a way which gives them access to the secure content, injected some javascript for example.

However once you have viewed an HTTPS page with mixed content, Google Chrome will continue showing you the mixed content warning (a red line through the 'https://') for as long as you stay browsing the same domain, even for subsequent pages which only include other HTTPS resources. Only once you navigate to another domain, or open a fresh tab does it tell you you're secure again.

What is the danger it's protecting you from here? How could mixed content on a previous page actually affect the security of subsequent secured pages? I understand that mixed content should be flagged up, but there must be a specific reason that Google is persisting this warning, other than "Well you still need to know about it"

1 Answer 1


The biggest problem in using mixed content is, that (without preventing it explicitely) cookies are sent to both requests. That means, a session cookie which should be used with a secure HTTPS connection, will be sent also to an unsecure HTTP page request, or even for a request of a picture.

If an attacker can read this session cookie, he can access the site with the same priviledges as you do (if you are logged in, he is logged in as well). It doesn't help that you are switching back to HTTPS only, because the session is already hijacked.

  • That's a good point, I'd not considered access to cookie-based session IDs. I'll run some tests with HTTPOnly cookies (which aren't available to javascript) and see if that holds. However, if this is the reason, Chrome seems to be inconsistent in its behaviour, because closing a tab and reopening it clears the "taintedness" of the session, whereas the problem you describe would still exist.
    – Gareth
    Jan 25, 2012 at 13:46
  • @Gareth - I'm curious about the result of your test with HTTP-only cookies. Is there a difference, and did the browser keep the session after closing the tab (if the session cookie was deleted automatically, the next call would be safe again)? Jan 25, 2012 at 14:39
  • I'll post the results when I get some time to test it, but Chrome definitely keeps the session cookie for longer than any individual tab is open - until the whole browser is quit as far as I know
    – Gareth
    Jan 25, 2012 at 14:47
  • @Gareth - I misread your first comment, testing HTTP-only cookies won't solve the problem, what could help is to use HTTPS-only cookies. Jan 26, 2012 at 7:47
  • Setting a secure-only session ID cookie will mean that the application simply won't work if there's a need to switch between secure and non-secure pages. I was talking about owasp.org/index.php/HttpOnly
    – Gareth
    Jan 26, 2012 at 10:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.