vintasoftware / django-react-boilerplate

Django 5, React, Bootstrap 5 with Python 3 and Webpack project boilerplate
MIT License
2.01k stars 481 forks source link

django-breach no longer needed as of Django 4.2 #665

Closed BrendanJM closed 6 months ago

BrendanJM commented 6 months ago

Describe the bug django-breach is no longer needed as of django>=4.2.0, from https://github.com/lpomfrey/django-debreach:

Note (that as of version 4.2 Django) includes this protection natively and this library is not needed.

I'm not sure what are the full set of configurations needed to conform to the Django native model here. From the 4.2 release notes (https://docs.djangoproject.com/en/5.0/releases/4.2/#mitigation-for-the-breach-attack) it looks like we'd want to use django.middleware.gzip.GZipMiddleware.

It seems like adding to MIDDLEWARE may be sufficient?

MIDDLEWARE = [
    "django.middleware.security.SecurityMiddleware",
    "django.middleware.gzip.GZipMiddleware",
    ...
]

We can confirm responses are encoded:

 curl -I -H "Accept-Encoding: gzip, deflate" http://localhost:8000/

Response:

HTTP/1.1 200 OK
...
Content-Encoding: gzip
...
fjsj commented 6 months ago

Thanks for the heads up. The GZipMiddleware is the one that introduced the BREACH issue. Now that it includes the BREACH protection in it, we can keep using it and remove django-debreach. I'm not sure we really need debreach in current main branch, because AFAIK the BREACH attack requires compression. See "Am I affected?" in breachattack.com. That said, we can add the GZipMiddleware back and remove django-debreach.

BrendanJM commented 6 months ago

Got it - that makes sense! I wasn't super familiar with this plugin or the BREACH attack, but reading a bit more it does seem to be limited to compressed responses. So it seems as though leaving it out of the middleware is fine, and those who need compression would just add it and receive the protections.