Skip to content

The Future of Tag Management – Part 1: Content Security Policies

Published by Cory Underwood on October 21, 2019

Tag Management—it’s quick, fairly straight forward (if you can believe the marketing), and I feel is likely to change for more companies as we transition into 2020.  In the next few blog posts, I’ll look at three factors that could drive companies to examine their workflow and explain the issues as I see them.  I’ll then conclude this series of blog posts with my recommendations on how to address the issues identified in the first three parts.

I am quite curious as to what the client side tag platforms will be doing/advising going forward. I’d like to address the following questions:

  • Will server side be the way of the future for businesses dealing in e-commerce and advertising?  
  • Will the advertising attribution be lost forever more? 
  • Is this the end of tag management without developer involvement?  

There are so many questions and I don’t have all the answers.  However, let’s see if we can understand the issues and come to a path forward together over the next several weeks. 

I think a brief look at why tagging ends up in Marketing is in order.

  • It’s ‘one touch’ for development (initial setup).
  • It lets you deploy / remove tags easily.
  • It commonly sits outside typical developmental timelines.
  • It can commonly be done faster / has tighter timelines as it doesn’t require code deployments in the traditional sense.
  • Commonly less expensive because it bypasses development.

I’d like to discuss why I believe a shift is likely to occur away from marketing over the next several months, this belief is based on the increase in “Magecart” style attacks combined with the recent browser privacy changes.

What is Magecart?

Magecart is an attack designed to skim payment information from websites via not attacking the website directly, but attacking 3rd parties which the website ‘trusts’.  Loading in this trusted context allows the attacker to intercept information about the page sends the data to the attacker. In effect, they can use something like a tag manager to steal credit card information.  

We’ve seen the rise of “Magecart” style cyber-attacks in 2019. It’s a serious threat, to the point that the PCI Security Standards Council and Retail and Hospitality ISAC issued a warning about it.  Specifically:

Third party services and products should be reviewed to identify the impact on the organization’s PCI DSS (Payment Card Industry Data Security Standards) scope. It is recommended that organizations prohibit external assets on pages that accept cardholder data,as it extends the cardholder data environment scope to any environment hosting those assets. Customer contact portal vendors are an example of third-party service providers that should be reviewed as part of the organization’s scope. Removing or disabling unnecessary plug-ins and services is also recommended(PCI DSS Req. 2). It is important to ensure that any third-party scripts that are present in other areas of the website cannot gain access to payment pages or other sensitive areas(PCI DSS Req. 2 and Req. 6).Securing of third-party infrastructure and restricting access and permissions of third-party scripts to only trusted sources is also essential. Merchants should clearly identify the specific PCI DSS requirements covered by the service provider, and any requirements that are the responsibility of the service provider’s customers to implement. Organizations should actively monitor for and block attempts to introduce malicious code on to their e-commerce space. Permitting externally hosted JavaScript or Cascading Style Sheets(CSS) on payment acceptance pages should not be allowed. Where feasible, transitioning from using third-party hosted scripts to using internally hosted copies of third-party scripts could significantly decrease the risk of malicious modification. Third party scripts should be monitored to detect changes and the changes be reviewed to identify any potentially malicious code before implementation. Using content security policies (CSP) to restrict compliant browsers from executing JavaScript from sources which have not been explicitly whitelisted is also an added protection that should be incorporated.

That’s a lot of text —what does that mean exactly?

  • You shouldn’t use 3rd party code in places with access to payment information.  Examples (Tag Managers, Tags, External Fonts, Chatbots, and so on).  
  • If you do use 3rd party code you should monitor and block attempts to infect the payment flow with compromised code and validate the PCI Compliance of each supplier of said code.

In practice—from a tagging point of view—everything should be internally hosted (and verified) or shouldn’t be loaded without a security review and the ecommerce flow should enforce this via Content Security Policies, at minimum. Attempting to bypass these policies will result in the tag not working by design and result in data loss in an effort to reduce risk from having payment card information stolen.

What is a Content Security Policy?

A Content Security Policy is defined by Mozilla as:

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribution of malware.

A description of XSS is outside the scope of this article, but a detailed review can be found here.

This is a response header on the web page request which is roughly akin to placing a security guard in a building lobby.  The guard isn’t going to run a background check on you, but they are going to make sure your badge qualifies you to be in the building.   The net effect here is the page has a whitelist. If you’re on the list, you can load the resource/run the code and so forth.  If you are not on the list, you get rejected and shown the door.

Setting this up normally requires changing how the web server delivers pages and requires work with a development team.  This means if the tag is added to the container, the tag may not load unless the correct Content Security Policy is also deployed to allow that tag to load and execute. 

How do you deploy CSP with [x] Tag Manager?

I’d like to suggest that you work with your development and security teams before insisting on any of the following.  You want to be sure this meets your PCI-DSS / Security responsibility and figure out your workflow for introduction and removal of tags.

It is important to note that you have to add a policy for not only the tag manager, but for every tag inside the container you are deploying. Provided that tag is loading external resources.

How may the workflow change?

Let’s say you implement content security policies for all the vendors in your tag container.  If the vendor changes things in a way that causes it to no longer meet the policy, that code won’t be loaded by design resulting in data loss.  Thus, IT involvement increases for setup and maintenance for each vendor. 

On the other hand, let’s say you decide to host the files locally.  Now if the vendor introduces a change, it won’t automatically be picked up by design resulting in possible data loss until a code deployment can be arranged to patch the library that you are hosting internally.   Thus IT becomes part of the workflow for updating tagging libraries. This may mean you can’t use the tag templates in your tag manager and have to modify/craft custom ones to point to your locally hosted files.

Let’s say you opt to remove all the tags from any page with payment card data—this could create holes in your analytics and tracking and require changes to the website that may be more extensive than you could reasonably do.  You also have to keep up with website changes and add/remove the tag manager and its tags as needed.

You also have the option of moving all the tagging server side via a solution such as Segment.  This may make the most sense for some organizations as by removing the tags from the browser, you eliminate the Cross Site Scripting attacks that the Content Security Policies are designed to mitigate. It may also result in less reliance long term on your developer teams and reduce the chance of things randomly breaking due to external changes beyond your control.

The case for more developer involvement 

So based on the above sections, I don’t feel the average marketer has the skill set or should be expected to do the following:

  • Actively monitor for and block attempts to introduce malicious code on to their e-commerce space.
  • Permitting externally hosted JavaScript or Cascading Style Sheets(CSS) on payment acceptance pages should not be allowed.
  • Third party scripts should be monitored to detect changes and the changes be reviewed to identify any potentially malicious code before implementation. 
  • Using content security policies (CSP) to restrict compliant browsers from executing JavaScript from sources which have not been explicitly whitelisted is also an added protection that should be incorporated.

The above falls into the realm of computer security—which is a very detailed realm that many developers don’t have extensive experience with.  I don’t believe it’s reasonable to place the burden of automated scans and the like on anyone except the computer security professionals. While I believe it should be in the hands of the security staff, everyone involved in tagging should at least be aware of what is going on at a high level because it could matter for tag execution and analysis.

I do believe organizations should keep payment and personal data secure; I’d advise working with the security and legal teams to come up with a viable strategy, modifying your workflow as required to ensure that data is secure on page, in flight and at rest.

Content Security Policies—In Conclusion

Data Breaches are getting more expensive, with the average for 2019 being $3.92 Million Dollars. I believe given the heightened focus on security over the past few years, it’s just a matter of time before Content Security Policies become commonplace for certifications like PCI-DSS.

I suspect that a greater shift in workflow will occur for those companies whom this is not already common place—requiring developer involvement at minimum to setup and maintain a viable tag management program long term. The question is: is the industry heading in that direction?  Perhaps they’ll decide that’s too much effort and pursue a server side tagging solution. Maybe, just maybe—they’ll say Content Security Policies don’t go far enough and ask for Subresource Integrity validation—and that’s where we’ll pick up next time.

Check back soon to learn more about: Subresource Integrity and Tagging

Published inSecurityTag Management