SecurityTech Community

Avoiding “False Friends” on your website with Content Security Policy (CSP)

Barely any website these days works without 3rd party support tools. Analytics, APM or Error Logging are just a few sample use cases. From an integration point, these systems require the website operator to either include a JavaScript or a Pixel from a 3rd party host. Whereas a pixel “only” is able to create and read cookies (3rd party only, via HTTP) and track the user, a JavaScript gives much more power to the 3rd party, such as user interaction, modification of website content, measure timings or even read passwords.

Hence, it is pretty obvious, that as a website operator, you have to trust your partners and not include any arbitrary JavaScript. By attacking a partner and modifying the

JavaScript included in your website, an attacker would get the possibility to steal user information from your site, without you knowing. This is called XSS (Cross Site Scripting).

A 3rd party loading more additional party JavaScript “piggy back” is a pretty common case these days, especially in the domain of performance marketing or affiliate marketing. By adding one performance marketing provider, you would end up in including even more 3rd JavaScript being loaded, cookies being dropped, and data being collected.

With GDPR in place, this now gets an additional dimension: for each of additional JavaScript being loaded, you are required to collect the consent from the user. Of course, as you trust your partner, you will have a contract in place which would name the cascading 3rd party JavaScript being used by your partner. Good idea, but hard to track and hard to execute. So, let’s better be safe than sorry. And this is where CSP (Content Security Policy) comes into play.

Content Security Policy are HTTP headers which are sent from the server/host to the browser of the user. The headers contain information on the hosts from which the browser can safely load resources such as images (tracking pixels) or JavaScript. By this measure, the server has the control over the whitelisted hosts, that the website operator trusts in. By this measure JavaScript or Pixels from unknown host will not be loaded by the browser of the user. From a consent perspective this gives more safety to the website operator.

As a nice side effect, as a website operator you also reduce the risk of Cross Site Scripting and loading time of your page. Current browser (SafariFirefox) already block certain 3rd party hosts, to limit tracking by 3rd parties and block domains that host harmful, privacy infringing or malicious JavaScript.

To “fake” more trust, large performance marketing operators such as Adobe or SalesForce therefore ask for domain delegation, so that at least their JavaScript is loaded from a subdomain of your website. These domains are hard to block and also allow the partner to drop a 1st party cookie in the name of the website operator. Therefore, delegation of sub domains should be handled with special care.

Anyway, Content Security Policy has to be applied with care, as you might accidentally block JavaScript modules which are required for a proper operation of the 3rd party service. So, make sure, you at first figure out which JavaScript are loaded piggy back before blocking them. And also have proper testing in place.

Gerald Madlmayr

CTO at Stylight. Motivated by: Writing Java Code, Docker, K8S, Machine Learning, High performance Teams

Related Articles

Check Also
Close
Back to top button
X