Cybersecurity glossary
What is BREACH?
Learn what the BREACH attack is, how HTTP compression over TLS leaks secrets via ciphertext length, which applications were at risk, and how to mitigate compression-based HTTPS exfiltration.
Definition
BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext) is a practical side-channel attack that recovers secrets reflected in HTTP responses by combining attacker-controlled input with server-side compression and observing the resulting TLS ciphertext lengths—without breaking the TLS encryption itself.
Why BREACH mattered
After TLS-layer compression was widely turned off in response to earlier research, many sites still compressed HTTP response bodies with gzip or similar codecs. In 2013, researchers showed that this remaining practice was enough for a new attack: BREACH—Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext.
BREACH demonstrated a hard lesson for HTTPS operators: encrypting a stream does not hide every property of the plaintext. When compression is adaptive, ciphertext length becomes a oracle. Secrets that developers assumed were safe “because TLS” could still leak through size differences across thousands of crafted requests.
What BREACH actually is
BREACH is a compression side-channel against HTTPS applications. It does not require a broken cipher suite. It requires an application pattern:
- The server compresses HTTP responses.
- A confidential value appears in the response (for example a CSRF token in HTML).
- Attacker-controlled data is also reflected into that same response.
- An observer can measure how large the encrypted responses are.
When the attacker’s guess shares bytes with the secret, compressors find more redundancy and the output shrinks. Guessing character by character turns that shrink/grow signal into secret recovery.
Channel property abused
TLS ciphertext length still correlates with compressed plaintext size, leaking comparison outcomes.
Application pattern
Secrets and attacker-influenced input appear together in compressible HTTP responses.
Typical prize
CSRF tokens and other reflected anti-forgery or session-adjacent values inside HTML.
Not a library CVE alone
Risk follows product design—compression plus reflection—more than a single OpenSSL bug ID.
How the BREACH attack works
Think of BREACH as repeated experiments against a compression oracle delivered over HTTPS.
Force many victim requests
Malicious content causes the browser to request a target page repeatedly, varying a reflected parameter each time.
Embed guesses next to the secret
Attacker-controlled input is reflected into the same compressed response that contains the unknown secret.
Measure encrypted sizes
A network observer records TLS record or response lengths for each guess.
Score compression wins
Guesses that match secret prefixes compress better and yield smaller ciphertexts on average.
Extend the recovery
The attacker locks in correct characters and continues until the full secret is reconstructed.
Abuse the stolen value
A recovered CSRF token or similar secret can enable forged state-changing requests as the victim.
Noise, MTU effects, and chunked encoding can make measurements harder, but the underlying oracle remains whenever compression ratios reliably track guess quality.
BREACH compared with CRIME and related issues
BREACH is part of a family of compression attacks against encrypted web traffic. The mechanisms sit at different layers.
| Property | BREACH | CRIME | BEAST |
|---|---|---|---|
| Primary lever | HTTP response compression | TLS/SPDY compression | Predictable CBC IVs (TLS 1.0) |
| Breaks encryption math? | No—abuses length leakage | No—abuses length leakage | Chosen-plaintext CBC recovery |
| Common target secret | CSRF tokens in HTML | Cookies in compressed requests | HTTPS cookies via CBC guessing |
| Main historical fix direction | Change app compression/secret handling | Disable TLS/SPDY compression | Upgrade TLS; fix IV handling |
| Still relevant if TLS is modern? | Yes, if HTTP compression + reflection remain | Mostly historical if TLS compression is off | Mostly historical on TLS 1.2+ |
Who was affected
Any HTTPS application that compressed responses containing both secrets and reflected input was in scope. That pattern was—and still can be—common in server-rendered pages that echo query parameters while embedding anti-CSRF tokens.
The highest impact paths were applications where recovering a token enabled account takeover actions: changing email addresses, initiating transfers, altering OAuth grants, or performing administrative operations. BREACH did not need to steal the password if a short-lived page secret was enough to authorize the next request.
CDNs and reverse proxies that transparently compress HTML without understanding which responses mix secrets and user input can widen exposure even when origin developers never thought about compression oracles.
Mitigations that actually help
There is no single packet filter that “detects BREACH” reliably across all apps. Defense is about removing the oracle or making it economically useless.
Remove the dangerous mix
Do not reflect attacker-controlled input into the same compressed response that contains high-value secrets.
Selective compression
Disable compression for pages or endpoints that embed CSRF tokens or other secrets, or compress only static asset classes.
Secret isolation
Serve secrets out-of-band from compressible documents, or use designs where tokens are not echoed into HTML bodies.
Length and rate friction
Randomized padding, request rate limits, and SameSite cookie discipline raise cost and reduce practical exploitability.
Application owners should also keep CSRF defenses defense-in-depth: SameSite cookies, careful CORS, and double-submit or signed token designs that do not require reflecting long secrets next to user input.
What practitioners should do today
- Inventory which responses use Content-Encoding compression (gzip, Brotli, deflate) and whether they embed secrets.
- Disable or bypass compression for HTML/JSON responses that contain CSRF tokens or other reflected secrets.
- Eliminate unnecessary reflection of query or body parameters into compressed pages.
- Prefer CSRF designs that minimize secret material in compressible documents where feasible.
- Review CDN and load-balancer compression settings—edge compression can reintroduce risk the origin disabled.
- Rate-limit noisy cross-origin or highly repetitive traffic patterns against sensitive pages.
- Treat ciphertext length as an intentional threat-model input whenever compression is enabled on authenticated content.
- Regression-test security pages after performance teams enable ‘compress everything’ optimizations.
Lessons BREACH left for web cryptography
BREACH reinforced that HTTPS confidentiality is not absolute metadata silence. Length, timing, and compression ratios remain observable. Security and performance teams share the same headers: turning on gzip for every HTML response is a product decision with cryptographic side effects.
It also showed why application-layer secrets matter. Transport upgrades alone did not retire BREACH after CRIME-era TLS compression disablement. The vulnerable pattern simply moved up the stack into HTTP.
The practical takeaway
BREACH recovers secrets from compressed HTTPS responses by watching which attacker guesses make the ciphertext shorter. Modern TLS versions do not automatically stop it. If your app still compresses pages that mix reflected input with tokens or other secrets, you still own a compression oracle—and you should remove that mix or turn compression off for those responses.
Related security terms
CRIME
Earlier compression-based attack targeting TLS/SPDY compression rather than HTTP-level gzip/DEFLATE.
HTTPS
HTTP over TLS—the deployment model where BREACH observes encrypted response sizes.
Cross-Site Request Forgery (CSRF)
CSRF tokens reflected in HTML were a common BREACH recovery target.
Content Security Policy (CSP)
Helps limit malicious page scripts that drive chosen-input requests during BREACH-style attacks.
Man-in-the-Middle (MITM)
Network vantage often used to measure ciphertext lengths across many requests.
Frequently asked questions
What is BREACH in simple terms?
BREACH is a way to steal secrets that appear inside compressed web pages. The attacker changes input reflected in the page and watches whether the encrypted response gets smaller—compression shrinks more when the guess matches the secret.
Does BREACH break TLS cryptography?
No. It does not decrypt AES or RSA. It abuses the fact that compression changes plaintext size, and TLS ciphertext length still reveals that size information to a network observer.
How is BREACH different from CRIME?
CRIME targeted TLS-layer or SPDY compression. BREACH targets HTTP-level compression (such as gzip) on responses, which remained common after TLS compression was disabled.
What secrets can BREACH extract?
Any secret that appears in a compressed response alongside attacker-influenced data—commonly CSRF tokens, session-related values embedded in HTML, or other reflected secrets with enough predictability.
What conditions does BREACH need?
HTTP compression on responses, a secret reflected in the response body, attacker-controlled input also reflected in the same response, and the ability to issue many requests while measuring response sizes.
Is disabling gzip enough?
Disabling compression for responses that embed secrets is a primary mitigation. Applications can also separate secrets from attacker input, randomize payloads, or use other length-hiding defenses—layered controls are stronger than one switch alone.
Does BREACH still matter today?
Yes wherever compressed HTML or API responses still mix secrets with attacker-controlled reflection. Modern apps should assume size side channels exist whenever compression and reflection combine.
References
Explore authoritative guidance and frameworks related to breach.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.