I am in charge of the applicative security of our application and would like to test our exposure to the BREACH attack.

Our django-based web application reflects filtered user-input and serves a CSRF token.

The way I understand it, BREACH exploits the HTTP compression algorithm of the response body (so our session cookie would be safe in the HTTP header) to find other instances of a particular user-input string.

But what if canary="somethingsomething" becomes canary="somethingsomething&quot as user-input? Is the canary part so relevant to the "guessability" of somethingsomething? My guess this removes the canary for automatic detection, but if the rest of the page stays the same, somethingsomething would still be vulnerable, but more difficult to identify, especially if there is more than one token in the page...

1 Answer 1


If the user input is reflected verbatim with each request, your method probably does not protect against BREACH.

The most certain way to defend django is to turn off Gzip compression.

Alternately, you can XOR the token with a different pseudo-random value for each request.

  • 1
    Note that the xor must be done on all unchanging secrets passed over tls, not just the csrf token. BREACH focused on the csrf token because it's an easy thing that every web app has, not because it's the only secret that can be attacked.
    – atk
    Commented Jul 11, 2016 at 2:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .