This is a defensive mechanisms that requires no work on the side of the web application developer, as it is enforced only by the browser without any HTTP header or so. Although you could produce a broken website if you rely on including active mixed content. To fix this in a web application you can use protocol relative URLs or relative URLs in general. An example for a protocol relative URL would be:
<a href="//example.com/whatever" />
In this example “http:” was omitted, so the browser will use HTTP or HTTPS to load the resource depending on how the current pages has been loaded. If you use HSTS you will not run into trouble with mixed content, since HSTS forces all other resources to be loaded over HTTPS.
Session cookies are a popular target. Also man-in-the-middle attackers try to steal session cookies. Even if the authentication is secured with TLS, if the rest of the communication goes over HTTP the attacker can simply read the session id and use it to impersonate the user. But let’s assume a web application is serving all pages over HTTPS. If passive mixed content, like images, are requested from the web server, the session cookie will be leaked over a insecure channel. This is a very common scenario to limit the performance impact of using HTTPS.
The solution is the “Secure” flag for cookies. This flag instructs the browser not to send the cookie over and insecure HTTP connection, but only over HTTPS. This effectively prevents such leaks.
The two defensive mechanisms we discussed today are simple improvements that limit the possibility of accidentally leaking any information or creating a vulnerability when the web application is not carefully developed.