I'm not all that familiar with BREACH, so please correct me on the parts I'm wrong about, but it seems that it's an attack that allows one to recover some data sent over TLS if compression on TLS and the protocol level is enabled.
In Django, this means that attackers could recover the CSRF token that's used to prevent cross site requests. This means anyone between you and a client could later have that client automatically make authenticated requests to your app, simply by visiting a site they control, without the knowledge of the user.
To protect yourself, the Django team recommends turning off compression either at the TLS level and at the HTTP level.
The only part you're wrong about is the compression on TLS part, it's not an 'and':
> While CRIME was mitigated by disabling TLS/SPDY compression (and by modifying
> gzip to allow for explicit separation of compression contexts in SPDY),
> BREACH attacks HTTP responses. These are compressed using the common HTTP
> compression, which is much more common than TLS-level compression. This
> allows essentially the same attack demonstrated by Duong and Rizzo, but
> without relying on TLS-level compression (as they anticipated).
and
> It is important to note that the attack is agnostic to the version of
> TLS/SSL, and _does not require TLS-layer compression._
In Django, this means that attackers could recover the CSRF token that's used to prevent cross site requests. This means anyone between you and a client could later have that client automatically make authenticated requests to your app, simply by visiting a site they control, without the knowledge of the user.
To protect yourself, the Django team recommends turning off compression either at the TLS level and at the HTTP level.