I have been thinking about how a developer restricted (for whatever reason) to serving an unencrypted site might protect themselves from threats such as overzealous ISPs injecting ads or notifications into their pages, or script kiddies in a coffee shop turning the developer's normally harmless code into an ad hoc attack site. My first thought was the Content Security Policy header, but I am now unsure.

It is my understanding that unencrypted http traffic, including the headers, can be modified by a malicious third party performing a man-in-the-middle attack.

If this is the case, then the Content Security Policy header would be vulnerable to modification or deletion. The attacker could then insert, and have the browser execute, whatever they wanted.

Does it then give the developer a false sense of security in being able to include a CSP on an unencrypted page without some sort of warning in the browser console about MiTM, or are the good reasons for including it enough to outweigh this?

  • 2
    CSP protects helps protect against attacks like script injection via XSS that don't involve a MiTM. Sep 28, 2015 at 21:18

3 Answers 3


Does it then give the developer a false sense of security ....

You understanding of the issue is correct. But if this gives the developer a false sense of security depends on the knowledge of the developer.

A properly educated developer should know that with a successful MITM attack everything can be changed in the traffic. This is not only restricted to modifying the CSP or for ad injection but in fact the whole contents and code on the page can be replaced with something completely different. That is instead of nice fluffy kittens it could serve some ugly malware.

  • Those who would most benefit from a warning would never get there, and those who do get there would be the sort to know or self educate themselves that it is an ineffective misuse of CSP... Makes sense.
    – S. Albano
    Sep 30, 2015 at 16:33

Your understanding is correct.

Anything that isn't authenticated, encrypted, and integrity-checked is insecure. Full stop. You can make the attacker work a little harder for things, but at the end of the day the attacker can get between the user and the server, and after that all bets are off.

Something like injecting ads already requires being in a MITM position, so yeah, they can just strip out your CSP headers. A mass attack that isn't customized at all might not be smart enough to do that yet, but it won't take long. End-to-end security, such as TLS, is the only way to go.

For what it's worth, if you absolutely must use unsecured connections and want some protections in your authentication (i.e. resistant to anything except a MITM), take a look at digest auth. It never sends the actual password, or anything password-equivalent, over the wire. It's also got at least some resistance to replay attacks. You could also implement something in JS, using asymmetric crypto or SRP or similar. That offers the advantage of even being able to transmit the data encrypted, though you're still vulnerable to an attacker just injecting JS that steals the plain-text data as soon as your JS decrypts it.

At the end of the day, though, that's more effort than TLS, for significantly less security. There very few situations where you absolutely can't use TLS. Even self-signed certs can be imported into a browser or have an exception added for that one site, and then the user will be safer than otherwise, as the attacker would need to present their own cert (which does not yet have an exception) and that will trigger another warning in the browser.

  • Yes, personally I use https with a recommended cipher suite. This line of thought/madness was in trying to come up with a suggestion for unencrypted sites that I frequent on how they could protect their users, without nagging about serving over https. Most users don't know how to protect themselves with a disposable virtual machine or VPN. I guess it is nagging FTW.
    – S. Albano
    Sep 30, 2015 at 16:49

A good question. CSP controls the behavior of the browser AFTER the HTTP content has already reached the browser. For example which domain images can be loaded from. It provides protection at the application level. Man-in-the-middle (MiTM) attacks on the other hand occur at the transport level, allowing the attacker to change the content including HTTP headers BEFORE it reaches the browser.

This means that the protection that the CSP header provides can be negated if content is served over plain HTTP. However MiTM attacks require special access to the communications path between the browser and server. If this access does not exist, for example because the attacker is remote, then it takes out MiTM attacks out of the equation. However it still leaves the application open to HTML injection, ad injection, script injection, etc through user generated content input into the page through normal means. So CSP still provides a layer of protection from remote attackers.

You must log in to answer this question.

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