FTR, the header was added as part of T285761: Add proper security headers to Query Builder.

Triage Notes:

• I @ItamarWMDE or other engineers in the team will try and asses the security risks involved with enabling this feature before we proceed

Unfortunately, it seems like we cannot do this as these headers were requested by the WMF security team it seems. In addition, this might expose us to some forms of clickjacking attacks, where other embedding sites will be able to steal some information from the embedded page.

If we were able to limit the iframe to the domain of the mooc we might have had grounds to consider this. However, there is no longer an option to have an allow list of embedding origins, as this is deprecated from modern browsers.

We might be able to try and set a Content-Security-Policy header with a frame-ancestors directive set to the domain of the MOOC. But I would still defer to advice from the WMF Security Team (tagging @sbassett here since they are the only contact I have in the team so far)

In T329121#8620995, @ItamarWMDE wrote:

Unfortunately, it seems like we cannot do this as these headers were requested by the WMF security team it seems. In addition, this might expose us to some forms of clickjacking attacks, where other embedding sites will be able to steal some information from the embedded page.

This is all correct, and why we'd discourage a revert of the status quo or, at the very least, likely rate it as at least a medium risk.

We might be able to try and set a Content-Security-Policy header with a frame-ancestors directive set to the domain of the MOOC. But I would still defer to advice from the WMF Security Team (tagging @sbassett here since they are the only contact I have in the team so far)

This is likely feasible, if it doesn't interfere with any potential X-Frame-Options: deny|sameorigin headers, and if the source list is kept to a minimum of absolutely necessary URLs that the Security-Team could review and assign any potential risk ratings.

That being said, the query builder is just static files. It could potentially just run on their page natively, maybe needs a few changes and a bit of documentation from us. Or am I missing some fundamental consideration?

In T329121#8636168, @Michael wrote:

That being said, the query builder is just static files. It could potentially just run on their page natively, maybe needs a few changes and a bit of documentation from us. Or am I missing some fundamental consideration?

Static files... which include a hefty amount of client-side JS, no? That's the security concern. If it can be bundled and deployed from just about anywhere, setting up a demo site on wmcs, etc. would likely be fine. As long as there was no confusion for users that it was, indeed, a demo site.

In T329121#8633970, @sbassett wrote:

This is likely feasible, if it doesn't interfere with any potential X-Frame-Options: deny|sameorigin headers, and if the source list is kept to a minimum of absolutely necessary URLs that the Security-Team could review and assign any potential risk ratings.

Thank you, this sounds promising, I'll dig deeper into it. I suppose we will be talking about exactly one URL from WMFR, is that correct @Lydia_Pintscher?

UPDATE: The second part of this Stack overflow response seems to suggest that this might be possible (where CSP is used and XFO will only be the fallback). I didn't proof this myself yet, however, and I'm not sure if I'll have time to get around to it soon.

In T329121#8640243, @ItamarWMDE wrote:

Thank you, this sounds promising, I'll dig deeper into it. I suppose we will be talkin about exactly one URL from WMFR, is that correct @Lydia_Pintscher?

I believe so. @Envlh, can you confirm?

I'm not sure there will be exactly one URL, but there should be only one subdomain (formations.wikimedia.fr). I'm awaiting confirmation from @mickeybarber.

Yes only this subdomain formations.wikimedia.fr.

Have you been able to advance on the subject @Lydia_Pintscher?