* Be served from a server that uses HTTP-level compression
* Reflect user-input in HTTP response bodies
* Reflect a secret (such as a CSRF token) in HTTP response bodies
is vulnerable, regardless of technology.
The mitigation strategies were given in the original paper[1], this announcement is just repeat of what's in there. That said, it's exactly the right thing to do, that's not a knock on Django.
From my understanding (which may be wrong...), the requirement of "Reflect user-input in HTTP response bodies" is actually pretty important. If the application only does this on POST requests, then it should probably be fine. Since an attacker cannot formulate a valid POST without the CSRF token (assuming the app is using CSRF tokens correctly), then there is no way for an attacker to get this attack bootstrapped.
If the application reflects GET request input in the response (eg `https://domain.tld?q=ASDF` results in some `value="ASDF"` being included somewhere in the response), then it is indeed likely vulnerable. This allows the attacker to simply continually change the value of `ASDF` as they guess and check for some secret on the page.
Of course, if your application is allowing untrusted POSTs to be made, then you will still have to worry about POST requests...
Absolutely, I'm just saying that your statement that it's the only must have is factually incorrect. I could include some sort of secret on every page, but since my blog doesn't reflect user input, it would be fine. I could also have a 'search' function that would reflect input, but without the secret in the body, the secret would be fine.
All three parts are a must-have, even if they are incredibly common. Saying otherwise is misleading.
The mitigation strategies were given in the original paper[1], this announcement is just repeat of what's in there. That said, it's exactly the right thing to do, that's not a knock on Django.
1: http://breachattack.com/#mitigations