After reading some popular questions and answer on this website about BREACH, the only advice seems to be: don't compress anything that might contain secrets (including CSRF tokens). However, that doesn't sound like great advice. Most websites are actually compressing everything, so I wonder what they are doing exactly to prevent BREACH. I just checked the page with the form for changing your password here on StackExchange, and it's compressed. It looks like everything is compressed on Google too, and a lot of other important websites that are supposed to care about security. So what are they doing to prevent BREACH?
Here's a list of possible solutions I've been able to gather:
- Disable compression completely. This means wasting bandwidth and no one seems to be doing this,
- Only compress static resources like CSS and JS. Good idea, that's the quickest solution to implement, and that's what I plan to do on a few websites that I need to optimize.
- Checking referrers and avoid compression whenever the requests from unauthorized websites. Interesting idea, but it almost sounds like a "dirty trick" and it's far from perfect (some clients suppress referrers, all traffic coming from other websites and search engines will end up loading uncompressed pages, etc.)
- Rate limiting the requests. This it definitely implemented by Google, since if you click on too many links too fast you might see a CAPTCHA (it happened to me sometimes, while checking a website's position in the SERP, I was literally behaving like a bot). But are websites really relying on this to mitigate BREACH? And is it even reliable? What is a sensible and effective limit to set, for example?
- Use CRSF tokens in HTTP headers instead of the body of the page. I haven't noticed something like this on StackExchange, but Google seems to have interesting HTTP headers that look like tokens. I guess this will really mitigate the issue, provided the tokens are always checked (even just to display information, not only to change it). I guess this is the perfect solution, but it's the hardest to implement unless you do it from scratch (it would require rewriting several parts of your application).
So the questions are: are the above points valid? Are there any other options? And what are the websites that follow best practices actually doing?