Add Support for Cross-Origin Embedder Policy and Cross-Origin Resource Policy Headers

[meggles711]

I would like to add support for the COEP header, as well as CORP which is required to support this header, in Django.

What is Cross-Origin Resource Policy?
This header conveys to the browser that it should block no-cors requests to the given resource that are cross-origin or cross-site depending on the header’s value. This prevents information leaks and blocks the response before it enters an attacker’s process.

The CORP header can have one of three values. If set to “same-origin”, the browser will block any cross-origin no-cors requests. If set to “same-site”, the browser will block any cross-site no-cors requests. If set to “cross-origin”, no-cors requests are explicitly allowed to load this resource.

What is Cross-Origin Embedder Policy?
COEP, when used with the cross-origin opener policy header, is used to create a “cross-origin isolated state” for your site. This state prevents the modification of document.domain and makes cross-origin requests less dangerous. It also allows developers to use otherwise dangerous features like SharedBufferArray, performance.measureMemory, and the JS Self-Profiling API.

When set, COEP instructs the browser not to load cross-origin resources into the document unless they give explicit permission using CORS or CORP. Because of this, COEP can only be effectively used if developers also have the ability to set the CORP or CORS header. COEP can only be set to one value, “require-corp”.

Proposed Changes to Django
Django users should have the ability to set the COEP and CORP headers. Support for them should be added as a part of the security middleware. COEP should default to “require-corp” and CORP should default to “same-origin”.

[Mariusz Felisiak]

Cross-Origin Embedder Policy spec is still ​preliminary and may change at any moment. Also, ​Cross-Origin Resource Policy is not supported by all browser (e.g. Opera) and implementations on Chrome and Firefox have some bugs.

We can reconsider this ticket when specifications and implementations become more mature and stable.

[Adam Johnson]

The headers are now in the HTML Specification:

• COEP: ​https://html.spec.whatwg.org/multipage/origin.html#coep
• CORP: ​https://fetch.spec.whatwg.org/#cross-origin-resource-policy-header

The PDF Chrome bug referred to by MDN seems to have been fixed through a revert (​original bug, ​bug it was merged into, ​a revert of the problematic PDF behaviour).

The Firefox bug referred to by MDN is also fixed: ​https://bugzilla.mozilla.org/show_bug.cgi?id=1638323

I think it makes sense to add these headers to Django for 4.0 - thoughts?

[Carlton Gibson]

Adam, can I ask you to put your mind to how we might encapsulate these headers (​as per the mailing list thread)?

I imagine there's no perfect option here.

Maybe a class (a namespace) with class attributes for each header. Many users would never need to think about this. Those that did could define a single subclass (in a project/conf/default_header.py) and set that.

Maybe something different but, we should establish sensible defaults and then allow users to not need to confront these details until they need to.

Beyond that, generally +0 if they've reached stable status.

[Florian Apolloner]

Yeah I think you could add those know. An probably also COOP (Cross-Origin-Opener-Policy) and the acronyms are getting ridiculously confusing. Okay, the written header names as well but that is another story :D

As for the settings explosion, we should really start thinking about those. The security middleware will have quite a few after a while :d

[Adam Johnson]

Adam, can I ask you to put your mind to how we might encapsulate these headers (​as per the mailing list thread)?

I did follow that thread but couldn't formulate a great reply. I guess I lean towards Tim's arguments.

If we *were* to do a subclass-this-to-change-from-the-defaults I would make that class just SecurityMiddleware, with some class-level attributes. But it would be a lot of churn for the existing settings.

An probably also COOP (Cross-Origin-Opener-Policy) and the acronyms are getting ridiculously confusing.

COOP was added in #31840.

[Adam Johnson]

There's a PR for COEP here: ​https://github.com/django/django/pull/14318

I commented a couple things - I don't think we can add COEP without CORP, and CORP will require a per-view-override decorator like @csrf_exempt, for resources that really are intended to be shared cross-origin.