@sbassett As it happens, the only component of this service is the MachineVision MediaWiki extension, and as best I can tell, MediaWiki doesn't yet support CSP headers (see T28508: Content Security Policy (CSP) and https://www.mediawiki.org/wiki/Requests_for_comment/Content-Security-Policy). There is no external service component.

Other than CSP, I'm wondering, can you provide any guidance on what headers are needed beyond what we'll be getting "for free" by virtue of running in the WMF production?

@Mholloway - Er, Mediawiki supports CSP. Here it is on master and wmf.24. And here's some commits enabling its current report-only mode on production wikis: basically all wikis for auth'd users + small wikis + some private wikis. You can see some examples of the reports on channel:csp within logstash. There are a few outstanding items remaining for MediaWiki's CSP functionality (some Phab tasks here and there), the most challenging one being the setting of production wikis to enforce mode. Which, sadly, I cannot provide an accurate date for when this might be deployed.

That being said, there is some history of using ad-hoc CSPs outside of MediaWiki within various stand-alone apps (e.g. all of the service-template-based Node apps). And certain extensions like CentralNotice set their own CSP right now. And foundationwiki has its own, more aggressive CSP. While it isn't ideal, I believe the Security-Team is generally fine with these ad-hoc solutions until we can move to enforcing CSP within production wikis.

Change 542121 had a related patch set uploaded (by MSantos; owner: MSantos):
[mediawiki/extensions/MachineVision@master] WIP: add CSP headers to special page

https://gerrit.wikimedia.org/r/542121

So, I think the CSP header was the only unavailable security header that is already being applied by MW. I looked into other headers and found some phab tickets and discussions about their existence in MW. So my conclusion so far is:

• X-XSS-Protection: TBD if we need it T182535
• HTTPS Strict-Transport-Security: It seems that we are avoiding to solve this in the application layer T37079#1421214
• X-Frame-Options: Already available for Special pages
• CSP: https://gerrit.wikimedia.org/r/542121

@sbassett is my assessment correct? Am I missing something?

@MSantos -

This sounds correct though, admittedly, I don't personally have a full picture of the history of security header usage for Wikimedia projects. A handy tool that I often use for live sites is https://securityheaders.com. It should provide for a fairly thorough analysis of currently configured, misconfigured or missing security headers. For example, here's the report for MachineVision's mediawiki.org documentation page. A ZAP baseline scan can also be run against most development/private web applications, which returns a similar though less detailed report, including information on configured and missing security headers (see documentation here, I'm also happy to provide a quick tutorial/chat on how to run scans like this for development environments.)

Regarding the specific headers you mention above - I would de facto advise enabling these on every page unless they break critical functionality for a given web application. But to clarify a bit:

• X-XSS-Protection: less important these days as most modern browsers implement some form of this protection by default. However certain things can slip past such filters. Ideally, a strong, enforcing CSP would obviate the need for this header, though Mozilla still recommends it for older browser support.
• HTTPS Strict-Transport-Security: I believe this header is already enabled on most of the projects and certainly TLS is enforced at a few additional layers, notably here. So this shouldn't be an issue for any production-deployed extensions AFAICT.
• X-Frame-Options: I'd contend that this header should be enabled for every page possible as long as it doesn't break any existing, critical functionality or long-standing, legitimately non-nefarious use-cases. There's some debate over this (what and how serious various clickjacking attacks can be) but I would personally consider it a security best practice to enable whenever possible.
• CSP: r542121 looks fine, though 1) this will only protect that specific MachineVision special page - I would consider expanding to as many relevant MachineVision pages as possible 2) for now this will only generate the basic mediawiki CSP for production wikis, which is still only report-only and may be subject to change, especially as it transitions to enforcing.

Change 542121 merged by jenkins-bot:
[mediawiki/extensions/MachineVision@master] add CSP headers to special page

https://gerrit.wikimedia.org/r/542121

Note: OutputPage will automatically add CSP headers to special pages if configured, so you don't have to do anything on your special page to opt in to CSP headers (e.g. As an example, you can see that CSP headers are sent on https://en.wikipedia.org/wiki/Special:BlankPage )

[batch] remove patch for review tag from resolved tasks