CSP and the Experience Cloud

There is a new kid on the block of web security: Content Security Policy, or CSP.

It is not actually that new, but people start using it in earnest, and I have over the past months have had a couple of questions about how CSP influences Analytics and other parts of the Experience Cloud. So it’s time to think write about it.

I am not the first one to do so, of course. The help section has an article on Content Security Policies and the Marketing Cloud ID Service, which covers Marketing Cloud ID Service, Audience Manager, Target, and Analytics.

The article says that some domains need to be whitelisted:

1. *.omtrdc.net
2. *.tt.omtrdc.net
3. *.demdex.net

It doesn’t say how to do that, exactly. Looking at it, the second domain might also be covered by the first, right?

More reading needed…

CSP in a nutshell

Wikipedia defines Content Security Policy as follows:

Content Security Policy (CSP) is a computer security standard introduced to prevent cross-site scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context.

The idea is to send a header with every page, and in that header specify what the browser should be allowed to do.

If you want to know more about CSP, content-security-policy.com/ and the MDN seem to be a good resources.

For now, let’s create an example: if you want to experience the good old days of Mozilla 1.0, try adding the following CSP to your site:

	default-src: 'none';

Looks awesome:

Just switching to ‘self’ makes the whole thing look ok, again, but there’ll still be no tracking.

There are different things you can limit or open up with CSP, such as the loading of scripts and images, the execution of inline scripts, and much more.

You can (and probably do) safely assume that the Internet is hostile. Whatever you put out there will be attacked. One way to harden your offering is to reduce the attack surface, and CSP helps with that, a bit like a firewall does when it sits between a server and the Internet — so only open up what is absolutely necessary.

I guess your ops people do that, or they push hard for it.

The question for you, therefore, is: how do I make a CSP that allows the Experience Cloud solutions to work on a site?

I’ll try to answer that, based on my Google-fueled, omnipotent half-knowledge.

Simple CSP

The easiest way to build your first CSP is by using an online tool, such as (random find) Report URI CSP Builder. You can even test it safely by injecting it into your site using Charles’ Replace feature.

Given the domains above, a little bit of common sense, guesswork, and the CSP Builder, I came up with this:

	default-src 'self' assets.adobedtm.com *.omtrdc.net *.demdex.net;

Note that I added the DTM URL, because I load my DTM library directly from DTM. If you use “Library Download”, then ‘self’ covers it.

It works!

So the help article speaks the truth. I can’t help having a nagging feeling of inadequacy, though. This is a pretty simple policy, sure, but it could be much tighter.

It might make sense to replace the ‘self’ with my own domain. Have to think about that.

Is it only about script-src?

Other people argue that of all the directives in CSP, only script-src really makes a difference to the security of your site, mainly because all others can be circumvented if scripts are not tightly tied down.

While the site advocates Strict CSP, it also has good tips in general.

Using that approach, I came up with a second CSP:

	script-src 'unsafe-inline' assets.adobedtm.com *.sc.omtrdc.net *.tt.omtrdc.net *.demdex.net; object-src 'none'; base-uri 'none';

Works, too!

I think that we can make that a lot safer, though.

How about this:

	script-src 'unsafe-inline' https://assets.adobedtm.com https://*.sc.omtrdc.net https://*.tt.omtrdc.net; object-src 'none'; base-uri 'none';

Yup, works.

The difference is that scripts can now only be read via https.

Full Paranoia

Above, I added ‘https’. I wonder whether it makes sense to be more specific.

Example DTM: It’s ok to allow the browser to load from ‘*.sc.omtrdc.net’ and ‘*.tt.omtrdc.net’, but I could also be more specific and limit those to ‘https://adobeags055.sc.omtrdc.net’ & ‘https://adobeinternalags055.tt.omtrdc.net’. That should work, right?

	script-src 'unsafe-inline' https://assets.adobedtm.com https://adobeags055.sc.omtrdc.net https://adobeinternalags055.tt.omtrdc.net; object-src 'none'; base-uri 'none';

‘ags055′, adobeags055’, and ‘adobeinternalags055’ are my internal “company names”. Yours are different. The easiest way to find out yours is to check the calls that your site is making using Charles or your browser console.

Ok. And still works!

In order to go full paranoia, my first impulse would be to set default-src to ‘none’. Don’t allow anything by default. Why would you?!

You then obviously have to explicitly allow all the calls that the tools have to make individually. And that brings us to my last CSP, the most paranoid one:

	default-src 'none'; script-src 'unsafe-inline' https://assets.adobedtm.com https://adobeags055.sc.omtrdc.net https://adobeinternalags055.tt.omtrdc.net; img-src https://cm.everesttech.net https://dpm.demdex.net; connect-src https://ags055.sc.omtrdc.net https://dpm.demdex.net; child-src https://ags055.demdex.net; object-src 'none'; base-uri 'none'; upgrade-insecure-requests; block-all-mixed-content;

This time, I also supply img-src and child-src in the CSP, just for fun. They are both needed for the Marketing Cloud ID Service.

Note that the good old Analytics calls are no longer classified as images! I believe (but haven’t checked) that if you do not use MCIDS, they still might be.

Again, replace ‘ags055’, ‘adobeags055’, and ‘adobeinternalags055’ with the values you see for your site.

Notes

One final thing to say about CSP: the rules I show here only cover what is needed for the DTM, Marketing Cloud ID Service, Audience Manager, Target, and Analytics. You will obviously have to add to those rules to make your site work properly!

Example: my site loads CSS and some scripts from ‘self’, as well as jQuery from the jQuery CDN. It also shows some photos that are posted in my Google+ stream. All of those I have to add to the policy, or the site won’t work.

But I did not include them in this article, since I am pretty sure that if you are even reading this, you do so because the decision to use CSP has been taken somewhere, and the basic policy has probably been done.

Someone came to you with the question “Hey, we’re doing CSP now. Do you know what we need to specify for those Adobe tools to work properly?”

And, funny enough, now you do! Isn’t that a pip?!