我一直在考虑开发人员如何限制（无论出于何种原因）为未加密的网站提供服务，这可能会保护自己免受威胁，例如过分热心的 ISP 将广告或通知注入他们的页面，或者咖啡店里的脚本小子将开发人员通常无害的代码变成一个临时攻击站点。我的第一个想法是内容安全策略标头，但我现在不确定。
据我了解，未加密的 http 流量（包括标头）可以被恶意第三方修改，执行中间人攻击。
如果是这种情况，那么内容安全策略标头将容易被修改或删除。然后，攻击者可以插入并让浏览器执行他们想要的任何内容。
那么它是否会给开发人员一种错误的安全感，因为能够在未加密的页面上包含 CSP 而不会在浏览器控制台中出现某种关于 MiTM 的警告，或者包含它的充分理由足以胜过这一点？
那么它是否会给开发人员一种虚假的安全感......
你对问题的理解是正确的。但是，这是否给开发人员一种错误的安全感取决于开发人员的知识。
受过适当教育的开发人员应该知道，通过成功的 MITM 攻击，流量中的一切都可以改变。这不仅限于修改 CSP 或广告注入，实际上页面上的全部内容和代码都可以用完全不同的东西替换。那不是漂亮的毛茸茸的小猫，而是可以服务于一些丑陋的恶意软件。
你的理解是正确的。
任何未经身份验证、加密和完整性检查的东西都是不安全的。句号。您可以让攻击者更加努力地做一些事情，但最终攻击者可以在用户和服务器之间进行攻击，然后所有的赌注都没有了。
像注入广告之类的东西已经需要处于 MITM 位置，所以是的，他们可以删除您的 CSP 标头。根本没有定制的大规模攻击可能还不够聪明，无法做到这一点，但不会花很长时间。端到端的安全性，例如 TLS，是唯一的出路。
对于它的价值，如果您绝对必须使用不安全的连接并希望在您的身份验证中得到一些保护（即抵抗除MITM 之外的任何东西），请查看摘要身份验证。它从不通过网络发送实际密码或任何等效密码。它也至少对重放攻击有一定的抵抗力。你也可以在 JS 中实现一些东西，使用非对称加密或SRP或类似的东西。这提供了甚至能够传输加密数据的优势，尽管您仍然容易受到仅注入 JS 的攻击者的攻击，该 JS 会在您的 JS 解密后立即窃取纯文本数据。
不过，归根结底，这比 TLS 更费力，但安全性要低得多。在极少数情况下您绝对不能使用 TLS。甚至可以将自签名证书导入浏览器或为该站点添加例外，然后用户将比其他情况更安全，因为攻击者需要出示自己的证书（尚无例外） )，这将在浏览器中触发另一个警告。
一个好问题。在 HTTP 内容已经到达浏览器之后， CSP 控制浏览器的行为。例如，可以从中加载哪些域图像。它在应用程序级别提供保护。另一方面，中间人 (MiTM) 攻击发生在传输级别，允许攻击者在内容到达浏览器之前更改包括 HTTP 标头在内的内容。
这意味着如果内容是通过纯 HTTP 提供的，则 CSP 标头提供的保护可以被否定。然而，中间人攻击需要对浏览器和服务器之间的通信路径进行特殊访问。如果这种访问不存在，例如因为攻击者是远程的，那么它就排除了中间人攻击。然而，它仍然让应用程序对 HTML 注入、广告注入、脚本注入等开放，通过用户生成的内容通过正常方式输入到页面中。因此，CSP 仍然为远程攻击者提供了一层保护。