Content Security Policy And Its Impact On Web Tracking

With malicious activity, breaches, and data theft always rising, it has never been so important to focus on website security. For your business and your customers alike. And while web security measures constantly improve, hackers’ means and tools have also become more ingenious.

A Content Security Policy (CSP) is another tool in your toolbox that you should implement. But, as you add your policy, you might find that it negatively impacts your web tracking. This article details how to keep your Google Tag Manager working smoothly while protecting your website from malicious code.

Content Security Policy: An Overview

At the core of any website security strategy are HTTP headers. These response headers are responsible for telling the browser what actions to take. They also regulate the exchange of information between the user and the server, thus protecting sensitive data. A Content Security Policy is one of these HTTP headers that you can choose to implement on your site.

A CSP comprises several guidelines that tell the browser how to behave, regulating which sources are loadable. For example, you can specify from which domain scripts and images can be loaded or disallow inline scripts.

Thanks to these features, your CSP will protect users from malicious plugins and malware. It will also minimize the risks of cross-site scripting. Bear in mind that you are likely to face such risks, no matter how strong your website’s security strategy is.

The Relationship Between CSP and Web Tracking

Web tracking and analytics are a vital component of a business’s strategy. But collecting this data does not come without risks. This is true even if you are only using trusted third-party tools such as Google Analytics.

The primary role of a CSP is to ensure that the script, images, and sources on a user’s page are from safe sources. The policy does so by preventing malicious activity from third-party vendors and unrecognized domains.

However, a CSP can’t distinguish between the non-malicious code used by Google Tag Manager (GTM) or Google Analytics and malicious JavaScript. Therefore, if you wish to keep tracking your users’ activity, it is essential to optimize your CSP. You can do so by writing a CSP that recognizes and allows scripts coming from Google.

Should You Run The Risk And Keep Working With GTM?

Why does your CSP consider an authoritative and reliable source (i.e., Google) to be at the same level of malicious script? The answer is that what makes GTM so useful also increases your site’s vulnerability. 

GTM is nothing more than a container of JavaScript code blocks. This allows marketers and developers to modify, create, and swap Google and third-party tags. 

This flexibility and ease of use come at a price: everyone can add a new “custom tag” with minimal supervision. And, if your site does not have a CSP, it might easily allow users to load malicious images and scripts.

Using Google Analytics and GTM together is a powerful combination. For the two to work together, it is worth optimizing your CSP.

3 Efficient Ways To Optimize Your CSP for GTM

When optimizing your CSP for GTM, it can be tempting to just add script-src https://analytics.google.com/ and https://tagmanager.google.com/ to your policy. 

By doing so, you might get your GTM to work, but your custom JavaScript variables are likely to return undefined. This also happens by using the ‘unsafe-inline tag. 

Another solution many resorts to is to add the unsafe-eval argument. This will enable your GTM, but it will also allow the execution of any other script. In turn, this will cause your CSP to stop protecting your site. 

Instead of the examples above, you should try using a hash or a nonce. In any case, remember to always add accessible domains to your existing CSP – do not create a second one!

Use a Hash To Verify The Script’s Safety and Integrity

Start by checking that a certain source is trustworthy, safe, and reputable – such as Google. A hash verifies that scripts from that source have not been tampered with on the way to your site. If the source was originally safe and the hash ensures its integrity, it is safe to allow content from it. 

However, even alterations as small as adding space will cause the hash to render the script invalid. You may know this mechanism as SubResource Integrity (SRI), a strategy that developers widely use in popular scripts such as jQuery.

Use a Nonce For Consistency and Efficacy

Since GTM allows developers and marketers to create different tags and variables, the script will be different each time. In this case, hashes can become cumbersome and ineffective. Instead, you should consider using a nonce, which stands for “number-used-once.” 

All you will need to do is add the same nonce to your CSP and to your script tag. So, the browser will receive instructions that that content is safe. Before implementing a nonce, you should keep in mind that the chance is irreversible.

Teaming up with your developer

Removing the ‘unsafe-inline argument from your policy means that no random code can be executed. While this means that the site is becoming safer, you might struggle to collaborate with your developers. The fact is that they might tend to use custom CSPs with different options from a standard policy. 

What’s more, your developers might need to deal with challenges such as browser incompatibility. Or, the fact that they now have to avoid cache. In fact, since each nonce is unique, they will have to serve a different page to each user.

B-New can help you with your CSP configuration

Here at B-New, we take pride in providing secure, reliable digital performances. We understand that data analytics and processing are vital components of a successful business. But we also strive to make the digital world a safer place. Get in touch today to optimize your content security policy and streamline your web and app tracking.