[Django] #31923: Add Support for Cross-Origin Embedder Policy and Cross-Origin Resource Policy Headers
Django
Policy Headers
-------------------------------------+-------------------------------------
Reporter: | Owner: nobody
meggles711 |
Type: New | Status: new
feature |
Component: HTTP | Version: master
handling | Keywords: COEP, header, CORP,
Severity: Normal | security
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
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”.
--
Ticket URL: <https://code.djangoproject.com/ticket/31923>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
Policy Headers
-------------------------------------+-------------------------------------
| meggles711
Type: New feature | Status: assigned
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: COEP, header, CORP, | Triage Stage:
security | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: nobody => meggles711
* status: new => assigned
--
Ticket URL: <https://code.djangoproject.com/ticket/31923#comment:1>
Django
Policy Headers
-------------------------------------+-------------------------------------
| meggles711
Type: New feature | Status: assigned
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: COEP, header, CORP, | Triage Stage:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: Florian Apolloner, Adam (Chainz) Johnson (added)
* stage: Unreviewed => Someday/Maybe
Comment:
Cross-Origin Embedder Policy spec is still [https://wicg.github.io/cross-
origin-embedder-policy/ preliminary] and may change at any moment. Also,
[https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Cross-Origin-
Resource-Policy 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31923#comment:2>
Django
Policy Headers
-------------------------------------+-------------------------------------
| meggles711
Type: New feature | Status: assigned
Severity: Normal | Resolution:
Keywords: COEP, header, CORP, | Triage Stage:
security | Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by 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 ([https://bugs.chromium.org/p/chromium/issues/detail?id=1074261
original bug],
[https://bugs.chromium.org/p/chromium/issues/detail?id=961617 bug it was
merged into],
[https://bugs.chromium.org/p/chromium/issues/detail?id=1115149 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?
--
Ticket URL: <https://code.djangoproject.com/ticket/31923#comment:3>
Django
Policy Headers
-------------------------------------+-------------------------------------
| meggles711
Type: New feature | Status: assigned
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
Keywords: COEP, header, CORP, | Triage Stage:
security | Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Carlton Gibson):
Adam, can I ask you to put your mind to how we might encapsulate these
headers ([https://groups.google.com/g/django-developers/c/WJAbbwJKp30/m
/7At-ZvglAQAJ 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31923#comment:4>
Django
Policy Headers
-------------------------------------+-------------------------------------
| meggles711
Type: New feature | Status: assigned
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
Keywords: COEP, header, CORP, | Triage Stage:
security | Someday/Maybe
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by 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
--
Ticket URL: <https://code.djangoproject.com/ticket/31923#comment:5>
Django
Policy Headers
-------------------------------------+-------------------------------------
| meggles711
Type: New feature | Status: assigned
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
security |
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* stage: Someday/Maybe => Accepted
--
Ticket URL: <https://code.djangoproject.com/ticket/31923#comment:6>
Django
Policy Headers
-------------------------------------+-------------------------------------
| meggles711
Type: New feature | Status: assigned
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
Keywords: COEP, header, CORP, | Triage Stage: Accepted
security |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31923#comment:7>
Django
Policy Headers
-------------------------------------+-------------------------------------
| meggles711
Type: New feature | Status: assigned
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
Keywords: COEP, header, CORP, | Triage Stage: Accepted
security |
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/31923#comment:8>