HTTP Header disabling non-SSL (or TLS) content on this page

Question

Is there an HTTP Response header that disallows any non-SSL content from being displayed on the current page?

The idea is some times external content that needs to be on the website (cough, ad engines, cough) may be slacking off with the SSL and in such a case I'd rather skip on this external content, than provide an opportunity for active MitM with all its consequences.

I know HSTS covers similar ground, but AFAIK it works on a host basis; that is sending HSTS means you indicate you want only HTTPS connections to your host, not that you won't be including non-HTTPS content from the HTML of your pages.

Answer 1

You want Content-Security-Policy. The following rule should fit you (but do check the other interesting options it provides):

Content-Security-Policy: default-src https:;

There's a good explanation at http://www.html5rocks.com/en/tutorials/security/content-security-policy/

You can view the spec at https://w3c.github.io/webappsec/specs/content-security-policy/

Answer 2

To follow up on the current answer, there are some changes I'd suggest.

Content-Security-Policy: 
    default-src https:;
    connect-src https: wss:;
    form-action https:;
    upgrade-insecure-requests

The default-src https: is a good measure to ensure that assets are loaded over HTTPS, but the new upgrade-insecure-requests directive is much better in that it will try to fetch an insecure asset over a secure scheme rather than just block it.

The form-action https: directive also ensures that any forms on your website POST to a secure scheme, rather than an insecure scheme.

Lastly, the connect-src https: wss: directive will ensure a secure scheme for XMLHttpRequest, WebSocket and EventSource connections.

I have a CSP Cheat Sheet that covers all of the directives.

Answer 3

Theoretically, modern browsers block active mixed content and warn about passive mixed content. In that sense, the kind of blocking that you seek is already done on the client-side, to some extent.

You may want to serve the external content yourself by rewriting URL (that software might possibly help): the external content now becomes internal content that you provide on your own SSL. However, on a general basis, if the external content is not trustworthy (if only by being sloppily managed on the external server side), then the only sane practice is to evict it altogether -- which is what you are trying to do, indeed. Ideally you would serve "good" ads and not "bad" ads on technical per-ad grounds, but in practice you more have the choice between ad-network providers, or not having ads at all.