Closed BrendanJM closed 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.
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.
Describe the bug
django-breach
is no longer needed as ofdjango>=4.2.0
, from https://github.com/lpomfrey/django-debreach: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?
We can confirm responses are encoded:
Response: