If you want to add additional protection to your sites from certain web browser attacks, you can include a special HTTP header called the Content Security Policy (CSP) designed to instruct the browser how to best render and request resources such as images, styles, and JavaScript.
If you do not already have CSP settings in place, do not use this feature. This is only for sites that are using CSP settings already, or wish to add more security layers to their site.
CSPs can be implemented in a number of ways. For more information on how you can implement CSPs, visit Mozilla’s Content Security Policy (CSP) documentation.
Note
Make sure you are already using a CSP on your site before adding Kount’s CSP settings. Do not add CSPs to a web page unless the website is already using a CSP. If this is the only meta tag on a page with no other CSP setting, it might disable or stop other third-party JavaScript or iFrames and other off-site content from working properly.
CSP can be used with the HTTP header Content-Security-Policy with a string containing directives that control the rendering and requesting of resources. Here is an example of a <meta> tag in the <head> section of an HTML page:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; style-src 'self' 'unsafe-inline'; script-src https://ajax.googleapis.com">
Combinations of CSP directives are based on how the pages are built. For fingerprinting to work correctly, there are a few special directives to add.
For all Kount products, use https://*.kaptcha.com, as it is the recommended domain for our data collector.
Note
The domain name you use in the CSP setting must match the domain name you use for the src attribute. If these values do not match, the browser will block the downloading and running of the Device Data Collector JavaScript.
The following is the list of the CSP settings that need to be allowed for the kaptcha.com domain:
img-src https://*.kaptcha.com —
Informs the browser that images can be loaded from https://*.kaptcha.com. This is to load our logo.gif.
connect-src 'self' 'unsafe-eval' 'unsafe-inline' https://*.kaptcha.com —
Informs the browser to allow downloading of our JavaScript to create 1st party cookies and inject an unseen iFrame to run the collector code.
child-src https://*.kaptcha.com —
Informs the browser that child documents (iFrames) can be loaded from https://*.kaptcha.com. This ensures the iFrame that does all the work gets loaded.
script-src 'unsafe-eval' 'unsafe-inline'https://*.kaptcha.com —
Informs the browser that it is safe to run the JavaScript that creates the SDK client, sets up the callbacks, and initiates the data collection.
Refer to the following example HTML tag for Kaptcha. This should only be used in addition to or combined with other existing CSP meta tags on the site:
<meta http-equiv="Content-Security-Policy" content="img-src https://*.kaptcha.com;connect-src 'self' 'unsafe-eval' 'unsafe-inline' https://*.kaptcha.com; script-src 'unsafe-eval' 'unsafe-inline' https://*.kaptcha.com; child src https://*.kaptcha.com">
The HTTP Content-Security-Policy (CSP) trusted-types directive instructs user agents to restrict the creation of Trusted Types policies — functions that build non-spoofable, typed values intended to be passed to DOM XSS sinks in place of strings.
Together with require-trusted-types-for directive, this allows authors to define rules guarding writing values to the DOM and thus reducing the DOM XSS attack surface to small, isolated parts of the web application codebase, facilitating their monitoring and code review. This directive declares an allow-list of trusted type policy names created with TrustedTypes.createPolicy from Trusted Types API.
Trusted Types (CSP Header) with client-hosted Web SDK:
The Web SDK uses no innate XSS vulnerable functions. Enabling the Content-Security-Policy Headers should cause no interference with the ability of the Web SDK to collect data. However, depending on your method of transpiling the SDK, vulnerable functions might be introduced in the transpiled JavaScript. Be careful not to introduce any XSS vulnerable functions if you decide to enable Content-Security-Policy Headers.
Trusted Types (CSP Header) with Kount-hosted SDK (kaptcha.com):
There are two XSS vulnerable functions used in the Kount-hosted SDK, both are Function() constructor calls. Therefore, we recommend using the client-hosted Web SDK if you want to enable the Content-Security-Policy headers.