Overview of the Content Security Policy (CSP)
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.
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">
Kount directives for CSP
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.
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
connect-src 'self' 'unsafe-eval' 'unsafe-inline' https://*.kaptcha.com –
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'
Here is an 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">
Frequently Asked Questions
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.
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.
No. If you do not already have CSP settings in place, you do not want to use this feature. This is only for sites that are using CSP settings already, or wish to add more security layers to their site.