How to Prevent a BREACH Attack

A server vulnerable to a BREACH attack (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) allows an attacker to decrypt cookie contents such as session information. 

Learn how you can prevent BREACH attacks here.

BREACH Attack Security Assessment Level

SSL BREACH Security Assessment Level


BREACH Vulnerability Information

The BREACH attack can be considered an instance of the CRIME attack (Compression Ratio Info-leak Made Easy) attack vector as it is based on and largely follows its logic. It targets vulnerabilities in data compression in the HTTP protocol.

For a BREACH attack to be successful, several conditions must be met. Vulnerable websites must:

  • Use HTTP-level compression
  • Reflect user input (e.g., a username that is given from the login form) in the HTTP response body
  • Contain a secret (e.g., a CSRF token) in the response body that is of interest to the attacker

A server vulnerable to BREACH attacks allows an attacker to decrypt cookie contents such as session information, including login tokens, email addresses, and other types of sensitive data. 

This attack can be successfully executed in less than a minute.

Prevention Guide for SSL/TLS Vulnerabilities

Prevention Guide

Learn how to detect and prevent different kinds of SSL/TLS vulnerabilities.


How to Prevent a BREACH Attack

Unlike previous attacks such as BEAST or LUCKY 13, this attack does not require SSL/TLS-layer compression and can work against any cipher suite. For this reason, turning off TLS compression does not affect the possibility of a BREACH attack.

The attack is easier to execute against stream ciphers because the responses’ size is easier to establish. However, against block ciphers, attackers must work on aligning the output to the ciphertext blocks more precisely.

Technically, the easiest form of mitigation is disabling HTTP compression, which will lead to bigger sites that need to be transferred and is not a viable solution. 

Several ways of mitigating this attack exist. These include:

  • Disabling the compression-only if the referrer is not the own application
  • Separating any sensitive data (i.e., secrets) from user input
  • Using a CSRF token to protect pages that contain sensitive information thanks to the SameSite Cookie attribute
  • Hiding traffic length by including random numbers of bytes to responses (aka HTTP chunked encoding)
  • Randomizing token value in every response
  • Limiting the rate of requests 
  • Monitoring traffic to spot attacks as they occur


To disable HTTP compression from requests with different referrers, use the following settings:

SetOutputFilter DEFLATE
       BrowserMatch ^Mozilla/4 gzip-only-text/html
       BrowserMatch ^Mozilla/4\.0[678] no-gzip
       BrowserMatch \bMSIE !no-gzip !gzip-only-text/html
       SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|zip|gz|tgz|htc)$ no-gzip dont-vary
       # BREACH migitation
       SetEnvIfNoCase Referer .* self_referer=no
       SetEnvIfNoCase Referer ^https://www\.example\.org/ self_referer=yes
       SetEnvIf self_referer ^no$ no-gzip
       Header append Vary User-Agent env=!dont-vary

Possible BREACH Attack Solutions

HSTS – Secure Channels: Strict Transport Security

The server declares “I only talk TLS”

Example: HTTP(S) Response Header: Strict-Transport-Security: max-age=15768000; includeSubDomains

The header can be cached and also prevents leakage via subdomain-content through non-TLS links in the content

Weakness: “Trust on first use”

Certificate pinning

Server identities tend to be long-lived, but clients have to re-establish the server’s identity on every TLS session.

How could Google/Chrome be resilient to DigiNotar attack?

Google built-in “preloaded” fingerprints for the known public keys in the certificate chains of Google properties. Thereby exposing the false * certificate DigiNotar signed

But, preloading does not scale, so we need something dynamic:

Could use an HTTP header i.e. transmit the SHA1 or SHA256 hash of the Subject Public Key Info structure of the X.509 certificate. (You could pin to end entity, intermediary, root. Select your degree of precision.)

Secure Channels: DNSSEC for TLS

DNSSEC can be used to declare supported protocols for domains

DNSSEC can be used to declare a server certificate for the domain

Advantage: Advantage of trusted signed source

BREACH Attack Video Explanation

How to prevent BREACH attacks is explained in this short video.

Get a quick security report for your website for free now

We are analyzing
Scanning target
Scan status: In progress
Scan target:
Date: 01/12/2023
Crashtest Security Suite will be checking for:
Information disclosure Known vulnerabilities SSL misconfiguration Open ports
Complete your scan request
Please fill in your details receive the
quick security audit by email.
Security specialist is analyzing your scan report.
То verify your identity please provide your phone/mobile:
Thank you.
We have received your request.
As soon as your security audit is ready, we will notify you.