This will seemingly also require some server side configuration for it to be enabled on WMF projects

(In reply to comment #1)

will also require some server side configuration on WMF projects

Covered in bug 38516

The extension HSTS https://www.mediawiki.org/wiki/Extension:HSTS does exactly this (adding STS header) with some possibility to customise it per user, by means of BetaFeature if it is installed or a classical preference else.

Does it answer to the bug, or should it stay open to discuss about adding HSTS in MediaWiki core? (for the Wikimedia sites, see bug 38516.)

Since this bug is about MW and/or extensions rather than Wikimedia's infrastructure, I don't feel it's my place to close this off either. But I'll my add my $0.02 in any case:

• For Wikimedia specifically, we're not going to be setting this from the application layer, so we specifically don't have an interest in this.
• For all other installations' perspective, I would argue that setting HSTS from the application layer (or enabling it to be set easily, anyways) is probably always a bad idea. This is a potentially-dangerous header that needs careful consideration by whoever controls the HTTP server configs and the DNS for everything related to any domain pointed at a given wiki. Setting this header with good intentions (but without understanding the broader consequences) can be catastrophic, especially if the includeSubdomains tag is allowed. Is it intentional in the design of HSTS that there is no confirmation or opt-out for the users, and that there is no trivial way to undo or disable an HSTS setting without digging deep in preferences or clearing all browser state/history back to factory-default. As an example of worst-case scenarios:
  • foowiki, a wiki belonging to the owners of example.com, turns on HSTS headers in the applayer with a 1 year max-age. Any/all of the following scenarios can ensue:
  • Scenario 1: unknown to the foowiki admin that enabled it, the apache server that serves foowiki from example.com and foo.example.com, which supports both HTTP and HTTPS, actually splits traffic at the URL-level, sending /crazyapp/ to a completely different non-wiki application with mixed-content that can't yet be converted to HSTS. Every browser that hits foowiki now suddenly becomes forced to access the /crazyapp/ URLs over HTTPS as well, which breaks that site for them. They remember this for a full year even if you revert the header as soon as you notice the problem, and there is no simple way to fix that other than to ask all users to go deep in their browser settings somewhere and clear the bad HSTS setting.
  • Scenario 2: again unknown to the foowiki admin, some other department at the company has an apache server pointing at foowiki with URL splits for other unrelated domains like example.net and example.org as well, which suffer similar breakage.
  • Scenario 3: again unknown, a partner company has a completely separate site at example.biz, which also proxies traffic into the wiki, suffers same URL split issues as above.
  • And then to top it all off, if includeSubDomains was in the header, the effect spreads from those root domains to every subdomain of both domains, it's no longer just a URL path split scenario. There could be a completely-unrelated application (separate hostnames, IPs, servers, apaches, etc) running on the domain asdf.example.biz and/or xyz.example.com which can't yet transition to HTTPS due to mixed content, or lack of a valid purchase certificate, or lack of an HTTPS listener at all on those addresses, and those are now broken for a year as well.