Comment by okzgn

5 hours ago

An alternative: <meta http-equiv="Content-Security-Policy" content="script-src 'self' https://only-scripts-allowed-from-here.com">

This makes the client only load self-hosted scripts, or scripts only from the specified origins, among the other directives CSP allows (e.g. restricting styles, images, frames, etc.): https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

3 comments

okzgn

Reply
1vuio0pswjnm7  2 hours ago

If Cloudflare (CF) has r/w access to the response body, which CF does have by default, then CF can easily modify or remove that <meta> tag. The risk is not abated

The risk of third parties injecting scripts, etc., e.g., analytics, advertising, etc., into response bodies (web pages) is usually cited as a rationale for using HTTPS^1

CF somehow avoids the usual objections. CF is a MiTM but few people object

1. For example, a data collection, surveillance and advertising services company that operates a www search engine and releases a web browser may not want an ISP to inject scripts, etc., e.g., analytics, ads, etc., into web pages as it might compete with the company's business. As a defense against such ISPs and other third parties that are potential competitors for data collection/surveillance/advertising services, it might favor HTTPS sites in its www search engine results, promote HTTPS at conferences discussing its web browser, etc.

  • okzgn  1 hour ago

    Thanks for the background context, very interesting and realistic. Yes, of course it also has read/write access, though I always make sure there’s no interference of that kind. It has only happened to me once, where a binary I hosted on Pages didn't work when downloaded with wget (though that happened several years ago).