For Leverage to run as quickly as possible, an industry standard tool for compressing our web page is in use. Once the compressed web pages are received by the browser, it should decompress the web page and run as normal. However, with so many bad actors out there, network security tools are widely used to validate the content being sent to your browser before allowing it to decompress the web page for viewing. If your security tool determines that our web page content violates a specific policy, it can cause content header rewrites, block the content entirely, allow partial web page displaying, and more.
​
Since there is such a wide variety of security tools and each one has their own idea of what is a security best practice, it can be difficult for Leverage to format its web page content to adhere to every single security tool's expectations. As such our engineering team has found the best "one size fits all" for our content that will play nicely with most security tools. However, it will not be a perfect match for every security policy.

Below will be some information around how you can check if your security tools are causing this issue. It will cover how to capture network logs from your browser and how to check those logs for the errors commonly caused by security tools.

To check if your security tool is causing this issue, we first need to capture the network traffic on your browser when loading Leverage's website. The steps below will outline how we can capture these logs in our browser. While these steps are specific to the Chrome browser, other browsers support this same feature with virtually the same steps but, with some variations.

Once you have captured the network logs in your browser from Leverage, we'll need to check in the logs for specific errors.
​

Under the "Status" column you should see the status of loading specific resources from Leverage. Ideally nothing will be blocked, which would mean that none of the rows are in red text. However, there are some resources that are not strictly required and blocking these resources does not cause major issues.
​
The major resource here that need to not be blocked is the entry for main.XXXXXX.js (the "XXXXXX" portion here will always be changing based on the compiled version).
​

If your security tool has identified Leverage as a compressed page, it may be rewriting the headers of the resources to match the compressed type. The reason this causes issues is that your browser should automatically decompress this file into regular javascript but, with the header rewritten, your browser now doesn't know how to display the content.

There are a couple ways you can check for this. Firstly, if you see main.XXXXXX but it does not have the ".js" extension, this resource has a rewritten header.

If you do see the ".js" extension, then we will need to investigate further. By clicking on the row with main.XXXXXX.js it should open up more details about this resource. Under the subsection called "Headers" you are looking to find two headers, "Content-Encoding" and "Content-Type."

The above screenshot shows these headers in the form Leverage intends:

If these headers are not exactly the same as above, they are being rewritten and this is the cause of your issue.

Leverage's engineering team could adjust the content to match the security policies for every reported incident but, this fix could cause issues for users who it is currently working well. As such, the best way to address this issue is to adjust the individual security policy that is preventing the website from loading.

If you are part of the IT team that this issue is arising, some of our suggested fixes are:

Though these fixes are not guaranteed to solve your specific cause, we find that these typically address the root cause and allow Leverage to load uninterrupted.