Disable TLS compression, because CRIME exploits compression side channels to recover secrets from encrypted traffic. Also remove HTTP compression on responses that reflect attacker-controlled input and keep session secrets out of compressed, attacker-influenced content. Use current TLS configurations and test reverse proxies, load balancers and web servers for any remaining compression features.
How to reduce CRIME exposure without breaking traffic flows
CRIME is a compression side-channel problem, so the primary mitigation is to remove the compression feature that creates the oracle. In practice, that means disabling TLS-level compression first and then checking every layer that might still compress attacker-influenced responses, including reverse proxies, load balancers and application servers. For an encryption primer that helps frame why this matters, see Encryption Guide.
The practical goal is to keep secrets from ever sharing a compressed context with attacker-controlled bytes. If a web stack still performs HTTP compression on pages, headers or reflected content, the safest response is to turn that off for sensitive responses rather than trying to rely on application logic to keep the secret field separated.
Even when TLS compression is disabled, teams should still test for lower-layer or intermediary compression features that can recreate the same leakage condition. The fix is only complete when the full delivery path, not just the origin server, is verified.
Where the attack surface usually survives
CRIME is most dangerous where a secret and an attacker-controlled input are compressed together. That makes session cookies, anti-CSRF tokens and other bearer secrets high-value targets if they are reflected or echoed in compressed responses, especially through shared infrastructure that normalises content before delivery.
Attackers do not need full decryption capability. They only need repeated observations of length differences to infer whether guessed text matches secret material. That is why small configuration remnants, such as compression enabled on a single proxy tier, can preserve the attack surface even after the origin application has been hardened.
For a broader view of how encryption and transport controls are expected to behave in modern configurations, the CISA cyber threat advisories page is useful context, and current transport hardening guidance should be checked against what your stack actually enables.
What to verify before you call it fixed
Do not treat “TLS compression disabled” as the end state. Verify the complete request path, including CDN, WAF, reverse proxy and origin, because any one component that compresses attacker-influenced content can reintroduce measurable length leakage.
Also verify that sensitive values are not being copied into templates, error pages or reflected parameters that are eligible for compression. A secure configuration is only meaningful when the secret stays out of compressible content, not merely when the protocol setting looks correct.
If you need deeper operational guidance on the relationship between transport encryption and exposure from plaintext handling, the Encryption Guide is the most relevant internal starting point.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-8 — Transmission Confidentiality and Integrity | CRIME weakens confidentiality of data in transit. |
| SC-13 — Cryptographic Protection | The attack exploits a cryptographic transport feature interacting with content compression. | |
| Recommendation — Disable compression on sensitive traffic paths and validate transport confidentiality settings. Use approved TLS settings and remove features that create length-leakage side channels. | ||
| ISO/IEC 27001:2022 | A.8.24 — Use of cryptography | The mitigation concerns secure use of TLS and related cryptographic transport settings. |
| Recommendation — Review cryptographic transport configuration and eliminate compression-related exposure. | ||
| CIS Controls v8 | CIS-3 — Data Protection | Sensitive data must not be exposed through compression side channels. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Mitigation depends on finding hidden compression features across the stack. | |
| Recommendation — Protect sensitive data by removing compression from attacker-influenced responses. Harden every proxy, load balancer and web server so compression cannot reappear. | ||
Practitioner Guidance
What to verify: Confirm that compression is disabled at every layer that can process sensitive responses, not just in the web server or TLS stack you most often inspect. Then validate with an end-to-end test that no compressed response varies in a way that reveals secret-dependent length differences.
Common mistake: Teams often disable TLS compression but leave HTTP compression or intermediary compression enabled on content that reflects attacker input. That leaves the same side channel available through a different layer.
Decision rule: If a response can contain a session secret, token or other bearer value and is influenced by user input, treat compression as unsafe unless you can prove the secret is isolated from the compressed body.
Practitioner takeaway: The safest mitigation is not “make compression smarter”, it is to remove compression from any path where an attacker can measure secret-dependent length differences.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 18, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org