How does an application control whether or not its http content is compressed? I am not talking about TLS level compression, but rather about the compression of https:// response bodies only.

In cases where the response contains both anti-CSRF tokens and user reflected input, I believe such compression can lead to a BREACH compromise. So, then, how do I choose not to compress those responses?

closed as off-topic by AJ Henderson, Steve, Xander, Adam Katz, Anders Oct 24 '17 at 14:33

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "This question does not appear to be about Information security within the scope defined in the help center." – AJ Henderson, Steve, Xander, Anders
If this question can be reworded to fit the rules in the help center, please edit the question.


HTTP compression is controlled by the webserver, you configure IIS/Apache/Other as appropriate and this sets the compression header which your browser understands and treats the content as accordingly.

BREACH is a vulnerability in applications that use HTTP compression, reflect some sort of user input and also reflect a secret, such as - as you say - a CSRF token. the attacker then takes advantages of differences in the response sizes to determine secrets. There is a good explanation of BREACH here

Simple mitigations include disabling the compression which or may not be practical depending on your application. As the compression is performed at web server level, determining when to compress in the application may be tricky, a simpler approach is to inject noise the response on pages which are vulnerable. A random string of random length injected into the response is a good countermeasure if you wish to keep compression enabled.

Not the answer you're looking for? Browse other questions tagged or ask your own question.