BREACH 是在满足以下几个条件时出现的漏洞：

• 使用 HTTP 压缩，
• 一部分输入被反射，
• 响应的 HTTP 正文中存在静态机密，
• 攻击者可以读取加密响应的大小，
• 攻击者可以伪造对受攻击站点的请求。

这些条件中的每一个本身都不构成威胁，但它们结合起来会导致漏洞。这也是该漏洞没有明确解决方案的部分原因：仅仅升级 Apache 或 OpenSSL 是不够的。对所有内容禁用 gzip 压缩没有多大意义。在大多数情况下，反映用户输入是完全可以的。实际上并没有一个简单的解决方案，但在过去几年中，在缓解 BREACH 方面取得了一些进展。

最好的解决方案之一是相同站点 cookie 标志。这使得 cookie 不再适用于跨域请求，从而解决了 CSRF 攻击，从而也解决了 BREACH。有人正在制定一个规范，它已经在 Windows 10 上的Chrome、Firefox和Edge 中实现。Chrome 甚至正在努力使所有 cookie默认为 SameSite，从而解决 Chrome 中的 BREACH 和所有其他类似 CSRF 的攻击。

还有几个项目可以随机化响应长度。一些 模块在每个响应中放置一个随机的 HTML 注释，这完全是 hack。填充支持已在TLS 1.3中正式化，但在服务器中实现这需要一些时间。

一些框架还采取了措施来缓解 BREACH 攻击，特别是防止对 CSRF 令牌的猜测。Django在每个请求上随机化 CSRF 令牌，这样就不会在多个请求中猜到它。这是相对较新的，今年在 Django 1.10 中发布。

攻击者也取得了一些进展。今年研究人员表明，BREACH 也可以转换为计时攻击 (HEIST)，只需在浏览器中运行 Javascript 即可利用它。最后，今年还开发了一个新的工具包（Rupture）来利用压缩侧信道漏洞。