[Django] #36905: Remove safe parameter from JsonResponse

[Django]

#36905: Remove safe parameter from JsonResponse
-------------------------------------+-------------------------------------
Reporter: Timothy | Owner: Timothy Schilling
Schilling |
Type: | Status: assigned
Cleanup/optimization |
Component: HTTP | Version: dev
handling |
Severity: Normal | Keywords: security
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
The `JsonResponse` uses the `safe` parameter to limit responses to only
dictionary-like objects. This was to protect a security vulnerability in
browsers due to ECMAScript4. Browsers that use ECMAScript4 are
sufficiently old now that we can safely remove this.

This is currently [https://www.django-
antipatterns.com/antipattern/return-a-jsonresponse-with-safe-false.html
mentioned as an antipattern] on django-antipatterns.org, but it shouldn't
be any more due to adoption of ECMAScript5 which isn't vulnerable to this
exploit.

Flask [https://github.com/pallets/flask/pull/1671 did the same in 2016].
Their new [https://docs.djangoproject.com/en/6.0/ref/request-response
/#jsonresponse-objects security message is here.]

Regarding implementation, I suspect we could immediately deprecate this
parameter for the next major release and follow our typical deprecation
process. We should also reach out to django-antipatterns.org to have them
amend that article with our new stance.
--
Ticket URL: <https://code.djangoproject.com/ticket/36905>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#36905: Remove safe parameter from JsonResponse
-------------------------------------+-------------------------------------

Reporter: Timothy Schilling | Owner: Timothy
Type: | Schilling
Cleanup/optimization | Status: assigned
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
Keywords: security | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Description changed by Timothy Schilling:

Old description:

> The `JsonResponse` uses the `safe` parameter to limit responses to only
> dictionary-like objects. This was to protect a security vulnerability in
> browsers due to ECMAScript4. Browsers that use ECMAScript4 are
> sufficiently old now that we can safely remove this.
>
> This is currently [https://www.django-
> antipatterns.com/antipattern/return-a-jsonresponse-with-safe-false.html
> mentioned as an antipattern] on django-antipatterns.org, but it shouldn't
> be any more due to adoption of ECMAScript5 which isn't vulnerable to this
> exploit.
>
> Flask [https://github.com/pallets/flask/pull/1671 did the same in 2016].
> Their new [https://docs.djangoproject.com/en/6.0/ref/request-response
> /#jsonresponse-objects security message is here.]
>
> Regarding implementation, I suspect we could immediately deprecate this
> parameter for the next major release and follow our typical deprecation
> process. We should also reach out to django-antipatterns.org to have them
> amend that article with our new stance.

New description:

The `JsonResponse` uses the `safe` parameter to limit responses to only
dictionary-like objects. This was to protect a security vulnerability in
browsers due to ECMAScript4. Browsers that use ECMAScript4 are
sufficiently old now that we can safely remove this.

This is currently [https://www.django-
antipatterns.com/antipattern/return-a-jsonresponse-with-safe-false.html
mentioned as an antipattern] on django-antipatterns.org, but it shouldn't
be any more due to adoption of ECMAScript5 which isn't vulnerable to this
exploit.

Flask [https://github.com/pallets/flask/pull/1671 did the same in 2016].

Their new [https://flask.palletsprojects.com/en/stable/web-security/#json-
security security message is here.]

Regarding implementation, I suspect we could immediately deprecate this
parameter for the next major release and follow our typical deprecation
process. We should also reach out to django-antipatterns.org to have them
amend that article with our new stance.

--

--
Ticket URL: <https://code.djangoproject.com/ticket/36905#comment:1>

[Django]

#36905: Remove safe parameter from JsonResponse
-------------------------------------+-------------------------------------
Reporter: Timothy Schilling | Owner: Timothy
Type: | Schilling
Cleanup/optimization | Status: assigned
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:

Keywords: security | Triage Stage: Accepted

Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Jacob Walls):

* stage: Unreviewed => Accepted

Comment:

Thanks, TIL about this history.
--
Ticket URL: <https://code.djangoproject.com/ticket/36905#comment:2>

[Django]

#36905: Remove safe parameter from JsonResponse
-------------------------------------+-------------------------------------
Reporter: Timothy Schilling | Owner: Timothy
Type: | Schilling
Cleanup/optimization | Status: assigned
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
Keywords: security | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Adam Johnson):

* cc: Adam Johnson (added)

Comment:

A regular deprecation seems like the right approach to me. We can add a
fixer to Django-upgrade to strip the safe kwarg wherever it’s passed.
--
Ticket URL: <https://code.djangoproject.com/ticket/36905#comment:3>

[Django]

#36905: Remove safe parameter from JsonResponse
-------------------------------------+-------------------------------------
Reporter: Timothy Schilling | Owner: Timothy
Type: | Schilling
Cleanup/optimization | Status: assigned
Component: HTTP handling | Version: dev
Severity: Normal | Resolution:
Keywords: security | Triage Stage: Accepted
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Comment (by Timothy Schilling):

@Adam is the fixer to Django-upgrade something you think would be
reasonable for a new-ish contributor to be able to figure out? I assigned
this to me to hand off to a Djangonaut for the upcoming session.
--
Ticket URL: <https://code.djangoproject.com/ticket/36905#comment:4>