Brotli & BREACH: Security Guide

TL;DR

Brotli is a great compression algorithm, but it can be vulnerable to the BREACH attack if not configured correctly. This guide explains how to mitigate this risk by disabling Brotli for sensitive content or using appropriate caching headers.

What is Brotli?

Brotli is a modern compression algorithm developed by Google that offers better compression ratios than older algorithms like gzip. This means smaller file sizes and faster website loading times. Most web servers (like Apache, Nginx) support it now.

What is the BREACH Attack?

BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of HTTP) is a security vulnerability that allows attackers to steal sensitive information – like cookies or authentication tokens – from encrypted HTTPS connections. It exploits how compression algorithms handle repeated data.

Why Brotli & BREACH?

Brotli’s strong compression can *increase* the effectiveness of a BREACH attack compared to gzip, because it compresses repeating patterns more efficiently. If an attacker can inject content into a request and observe changes in the compressed response size, they can deduce sensitive information.

How to Protect Against BREACH with Brotli

1. Disable Brotli for Sensitive Content: The most effective solution is to disable Brotli compression specifically for pages that handle sensitive data (e.g., login forms, banking details). This prevents the attack from being possible on those critical areas of your site.
   • Apache: Edit your .htaccess or virtual host configuration file and add rules to exclude Brotli compression for specific URLs or directories. For example:

     <FilesMatch "^/sensitive-page.php$"
                     Header set Content-Encoding gzip
                 </FilesMatch>

   • Nginx: Modify your Nginx configuration file (usually in /etc/nginx/sites-available/your_site). Use the ngx_http_gzip_module to control compression. For example:

     location /sensitive-page.php {
         gzip off;
     }
     

2. Use Appropriate Caching Headers: Proper caching can limit the attack surface.
   • Cache-Control: no-cache, no-store, must-revalidate: These headers tell browsers not to cache sensitive pages. This reduces the chances of an attacker exploiting cached responses.

     Header set Cache-Control "no-cache, no-store, must-revalidate"

   • Pragma: no-cache: An older header that provides similar functionality to Cache-Control. It’s good practice to include it for compatibility.

     Header set Pragma "no-cache"

3. Content Security Policy (CSP): A strong CSP can help mitigate BREACH attacks by restricting the sources from which scripts and other resources are loaded. This makes it harder for an attacker to inject malicious content.
   • Configure your CSP header to only allow trusted domains:

     Header set Content-Security-Policy "default-src 'self'"

4. Regular Security Audits: Periodically scan your website for vulnerabilities, including BREACH. There are online tools and security professionals who can help with this.

Testing for BREACH

You can use online tools to test your site for BREACH vulnerability. Search for “BREACH attack test” on the internet.

Important Considerations

• HTTPS is Essential: BREACH attacks rely on encrypted connections (HTTPS). Always ensure your website uses HTTPS.
• Server Configuration: The specific configuration steps will vary depending on your web server and setup. Consult your server’s documentation for detailed instructions.