We emit X-Frame-Options: DENY on all "sensitive" pages (pretty much everything that displays a form, e.g. action=edit or special pages). We probably can't do that on all pages (neither DENY nor SAMEORIGIN), since various community tools rely on including pages from Wikimedia wikis in frames (for example, Wikidata Game: https://tools.wmflabs.org/wikidata-game/#mode=commonscat).

We have the code to emit Referrer-Policy, and it's enabled on production wikis ('origin-when-cross-origin' by default, 'no-referrer' on private wikis), but it doesn't seem to actually be in the output headers… Maybe it's filtered out by Varnish or something? Ignore me, I misread.

Content-Security-Policy

This is probably the header that would improve our security the most. I've been working on this, but progress has been very slow, largely due to lack of time on my part. See https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy and T135963 for more details. There are different levels of using this header, with different levels of changes required depending on how "strict".

Public-key-pins

Scary! This option if applied incorrectly has the potential to "brick" the site for a not short period of time, so it should only be applied after careful consideration (Operations folks are much more knowledgeable than me about what is needed to do this safely and properly). I personally think there are some security benefits of implementing it even if its done with a short max-age, especially being able to quickly "detect" when someone tries to do a MITM (A large-scale mitm attack, for e.g. censorship purposes would probably be detected by other means, but nonetheless it would be nice to have a more direct way of detecting an event like that) . But it is probably the most difficult and dangerous of all the headers mentioned here for less benefit than a several of the other headers. Anyways see T92002 for more details

X-Frame-Options

At the moment, we put this on pages where a user can do a write action by clicking on something (Most special pages (e.g. Note how recent changes gets a higher grade in the scanner: https://securityheaders.io/?q=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2FSpecial%3ARecentChanges&followRedirects=on ), ordinary articles that have a "patrol" link on them. Adding to watchlist is apparently not considered important enough to warrant the protection). Often gadgets add write actions on click. Currently this protection is not applied for that case, which is something that could be improved by adopting this header consistently. If we enabled it everywhere, people would no longer be able to frame wikipedia. Open question whether or not we should care about that, or if anyone else does care. It is after all, kind of useless to frame wikipedia with all the UI chrome still there. My personal opinion is that ideally we should disallow framing everywhere, and possibly introduce a new ?action=embed mode, which looks exactly like ?action=render except links keep the url parameter, for people who need to frame wikipedia. So in conclusion, needs more research, but probably pretty easy to implement (more-fully) for a small but good amount of security benefit. (I don't really see a bug for this, T48560 is kind of related though)

X-XSS-Protection

I'm not really familiar with the pro's and con's of this header. Ultimately Content-security-policy with no unsafe-inline is a more effective XSS prevention measure than this, works in firefox, and under no circumstance would have a false positive (but implementing that is much further away). We should probably research this and make an explicit decision on if we want this or not (instead of leaving it as default)

referrer-policy

We currently use a <meta> tag instead of the header (See T87276). The <meta> tag takes precedence over the http header (according to the HTML5 spec), and more browsers support the meta tag than the http header, so I so no benefit whatsoever to adding this as a header.

In T165455#3266388, @matmarex wrote:

We emit X-Frame-Options: DENY on all "sensitive" pages (pretty much everything that displays a form, e.g. action=edit or special pages). We probably can't do that on all pages (neither DENY nor SAMEORIGIN), since various community tools rely on including pages from Wikimedia wikis in frames (for example, Wikidata Game: https://tools.wmflabs.org/wikidata-game/#mode=commonscat).

In theory we could have a whitlist and then emit DENY or ALLOW-FROM depending on the origin, but it would have to be implemented in all kinds of things that render/cache wiki pages (MediaWiki, Parsoid, Varnish...) which is a bit of a pain. Maybe it could be limited to authenticated page views (framing an unauthenticated view seems pretty harmless).

In theory we could have a whitlist and then emit DENY or ALLOW-FROM depending on the origin, but it would have to be implemented in all kinds of things that render/cache wiki pages (MediaWiki, Parsoid, Varnish...) which is a bit of a pain. Maybe it could be limited to authenticated page views (framing an unauthenticated view seems pretty harmless).

Logistically, I'd personally like to avoid having a list of approved third parties and the process that has to go along with that. Allowing unauthenticated frames but disallowing logged in frames sounds sane at first glance (How would the third-party ensure the view is unauthenticated? Extra url parameter?)

In T165455#3266893, @Bawolff wrote:

How would the third-party ensure the view is unauthenticated? Extra url parameter?

Sandbox it without the allow-same-origin flag? The spec is a little vague on this but it seems like that would disable cookies.

This sounds interesting and important but I don't see anything that SRE could (primarily) do here, apart from HPKP which, as @Bawolff mentioned, has already its own task (T92002) with the proper tags attached to it. Security team, if there are any specific actionables for our team, feel free to open a subtask with the right tags so that we can help and/or investigate.

The REST API currently gets a "B": https://securityheaders.io/?q=https://en.wikipedia.org/api/rest_v1/page/html/Foobar

Missing headers are:

• Public-Key-Pins
• Referrer-Policy

Of these, only referrer-policy is directly actionable for Services. While this is not as important for APIs primarily consumed via XHR or fetch, it wouldn't hurt to specify it in any case. This is now tracked in T173509.