SAS Viya Behind a Gateway: Compression, Security, and Performance Insights

2 Likes

When deploying SAS Viya behind an HTTP gateway—such as Citrix NetScaler, Ergon Airlock, Azure Front Door, or any other reverse proxy, it's essential to understand how HTTP compression is handled.

Compression can significantly improve performance by reducing page load times and bandwidth usage, but it can also impact security if misconfigured.

A poorly tuned gateway may unintentionally block compression or introduce trade-offs that affect user experience or risk exposure.

Check Compression: Look at the `Content-Encoding` Header

HTTP compression can reduces the size of responses like JavaScript, CSS, and HTML. When compression is working correctly, the server returns a Content-Encoding header in the response.

Since SAS Viya content often requires authentication, using curl directly might not be feasible without handling authentication. Instead, you can use Chrome DevTools to inspect the headers of your requests:

Open Google Chrome and navigate to your SAS Viya application (https://<your-viya-url>/SASVisualAnalytics/).
Open Chrome DevTools by pressing F12 (or Cmd+Option+I on macOS) or right-clicking and selecting "Inspect."
Go to the "Network" tab.
Reload the page (Ctrl+R or Cmd+R) to capture network requests.
Find the request for a static file (e.g., a .js file) in the list of network requests.
Click on the request to see its details.
In the "Headers" tab, scroll down to the "Response Headers" section.
Look for the Content-Encoding header.

If you see a response header like Content-Encoding, your content is served compressed. In this case, compressed using the lossless Brotli compression algorithm, successor to gzip, and widely supported by all major web browsers.

Select any image to see a larger version.
Mobile users: To view the images, select the "Full" version at the bottom of the page.

If this header is missing and your static files aren't served in pre-compressed form (e.g., with a .gz file and matching headers), then clients are likely receiving larger, uncompressed responses, resulting in slower load times.

Security vs. Performance: The `Accept-Encoding` Dilemma

The BREACH attack exploits dynamic compression of content in HTTPS to extract sensitive data. One mitigation approach is to remove or suppress the Accept-Encoding header to disable compression entirely. While this does improve security, it comes at a performance cost—especially when static assets are involved.

SAS Viya web applications ship with pre-compressed static assets, like JavaScript, CSS which are compressed ahead of time during the build process and stored on disk as .gz or .br files. These files are served directly to the browser when supported, allowing clients to load smaller, optimized content without requiring the server to compress them on the fly. Because they are static and do not contain sensitive or user-specific information, these assets are not vulnerable to compression-based attacks like BREACH.

Disabling compression globally, for example, by removing the Accept-Encoding header, prevents clients from receiving these optimized files. This results in longer load times and increased data transfer, without adding meaningful security benefits for static content.

Why Pre-Compressed Static Assets Don’t Trigger BREACH
BREACH exploits dynamic content compression where user input affects the compressed response. Pre-compressed static assets (like .gz JavaScript files) are compressed ahead of time and contain no secrets or user-specific data. Because their size doesn’t change based on input, they are not vulnerable to BREACH—even when compression is enabled.

Instead of a blanket removal, consider targeted mitigation:

Apply BREACH protection only to dynamic endpoints that handle secrets and always assess the performance impacts.
Leave Accept-Encoding intact for static content such as JS, CSS.

Performance Comparison

Here’s an example comparing the performance of the SAS Visual Analytics main page with and without the Accept-Encoding header. These measurements were taken using the Playwright tool with caching disabled to simulate a full download experience.

Scenario	Average Load Time	Average Transferred Size
With `Accept-Encoding`	21.3 s	5048 KB
Without `Accept-Encoding`	35.6 s	20,366 KB

The difference is substantial: disabling compression increases transferred data by over 4× and raises load time by more than 65%. This demonstrates how critical HTTP compression is for performance, especially on resource-heavy pages like SAS Visual Analytics.

Conclusion

While the Accept-Encoding header can introduce risks on dynamic endpoints, especially in the context of BREACH, disabling it across the board is rarely the right solution. In environments like SAS Viya, where large volumes of static assets are delivered to users, compression plays a vital role in ensuring responsive, bandwidth-efficient user experiences.

Key takeaways:

Compression dramatically improves load times and reduces bandwidth usage for static resources (and this is why SAS Viya ships some content already pre-compressed)
Pre-compressed static assets are not vulnerable to BREACH and should be served with compression enabled.
Use selective BREACH mitigation techniques on sensitive, dynamic endpoints.
Always test your gateway configuration to ensure both performance and security goals are being met.

Find more articles from SAS Global Enablement and Learning here.