(This issue is public on purpose, we're not discussing a security vulnerability.)

There are a number of security related http headers you can set to help secure your site. This is primarily the responsibility of the site owner, since they generally have to be adapted to the site in question. However there are some we may want to set by default, or document as recommendations.

https://securityheaders.com/ uses these headers as a basis for their score, and you can scan any site there. Note that Google gets a D score, and Microsoft and Apple get a C. They arguably know what they're doing, which can be seen as a reason against panicking about this, but it's not a reason to be complacent.

• Strict-Transport-Security: Ensure all requests are over https, no fallback to http. We could set this by default, for new branches at least. Probably not as an update to existing sites as it may break dev sites, and any other site using http.
• X-Frame-Options: Ensure the site can't be embedded in a frame. As above, set by default for new branches.
• X-Content-Type-Options: Prevent the browser from second-guessing the mime-type of delivered content. Not important if users can't publish content, and you trust your editors. We need to check if there are downsides to this, I'm not sure yet.
• Content-Security-Policy (CSP): Whitelist approved sources, can block XSS. Useful, but it will break sites if we apply it to existing sites. Okay for new branches with doc. Must be adapted to each site. Document and recommend.
• X-XSS-Protection: Old, largely superceeded by Content-Security-Policy. Could be set to 0 to disable it, especially if CSP is set.
• Referrer-Policy: Limit what information is sent from the previous page/site when navigating to a new page/site. Also depends on what the site owner wants. Could be set to empty string by default, which is valid (no change). Document and recommend.
• Permissions-Policy: Limits what features the browser can use, like fullscreen, notifications, location, camera, microphone, etc. Very new, and limited usefulness unless you embed other sites, or unless there are ways that such features can be enabled by injected javascript, for instance. Must be adapted to each site. Document and recommend.

How to set such headers is another question. Varnish can do it, and the web server of course. The kernel.response event is another option, and would work regardless of webserver and proxy. We'd need configuration for it. It would need to be variable by site access at least, possibly also by path, prefix, etc.

Good up-to-date info about security headers: https://owasp.org/www-project-secure-headers/