Content Security Policies
Coming soon! This will be included in the February 28th release.
This requires developer level understanding of security headers and CSP directives
A Content Security Policy is a HTTP response header that can be used to enhance the security of a web page by dictating what assets (e.g., JavaScript files, videos, etc) can be loaded on it. This area of Engaging Networks provides greater control to Super Admins and allows them to either use an Engaging Networks defined CSP or define their own.
How to access Content Security Policies
The Content Security Policies are available to Super Admins by navigating to Hello > Security Center > Content Security Policies
Options for Enabling Content Security Policies
No policy
The default behavior for all accounts if no policy has been enabled. There will be a message at the top of the CSP area indicating there is no enabled CSP.
Engaging Networks (Standard)
This option uses an Engaging Networks defined CSP. It is designed to be a stricter policy that prevents inline script injection using nonce (“number used once”).
The Applicable Content Security Policy allows you to preview the CSP as it will be applied to your Engaging Networks pages. The Engaging Networks defined CSP includes all core Engaging Networks resources. Please see directives and allowed sources below to better understand how the Engaging Networks CSP is defined and how it works.
Define your own
This option allows you to define your own CSP. Select 
to begin adding elements to your defined CSP. See a list of available directives and what they control along with examples of allowed sources below.
Available Directive | What it controls |
|---|---|
| Specifies the default policy for fetching resources if no other directive matches. |
| Controls where images can be loaded from. |
| Controls where JavaScript can be loaded and executed from. |
| Controls where CSS stylesheets can be loaded from. |
| Controls where resources can be loaded via XHR, WebSockets, or Fetch API calls. |
| Controls where font files can be loaded from. |
| Controls where plugins like <object> or <embed> can be loaded from. |
| Controls where media (e.g., audio, video) can be loaded from. |
| Controls where <iframe> and <frame> content can be loaded from. |
| Applies restrictions to a page or specific resources (e.g., disables forms, scripts, plugins). |
| Specifies the endpoint where CSP violation reports are sent. |
| Deprecated. Previously controlled <iframe>, <embed>, or <object> resources. |
| Specifies valid endpoints for submitting forms (<form> tag actions). |
| Specifies which URLs can embed the site using <iframe>, <frame>, or <object>. |
| Specifies allowed MIME types for plugins (e.g., Flash, Java applets). |
| Specifies valid URLs for the <base> element, used to set a base URL for relative URLs. |
| An alternative to report-uri, integrates with the Reporting API to handle violation reports. |
| Specifies valid sources for workers (e.g., Web Workers, Service Workers). |
| Specifies valid sources for web application manifests. |
| Controls where resources can be prefetched or preloaded from. |
Allowed Sources | What it does |
|---|---|
| Allows resources to be loaded from the same origin as the page. |
| Disallows loading resources from any source. |
| Allows scripts dynamically added to the DOM (e.g., via appendChild) to load other scripts, but only if they are explicitly allowed by the CSP. |
| Allows resources to be loaded from blob: URIs, such as Blob objects created in JavaScript. |
| Allows resources to be loaded over HTTPS only. |
Specific Domains | Allows loading resources only from specified domains or subdomains (e.g., https://example.com). |
| Matches all sources or a specific part of a URL. For example: * matches all sources. *.example.com matches all subdomains of example.com. https://*.example.com matches subdomains of example.com over HTTPS. |
| Allows inline scripts or styles with a specific nonce attribute. Prevents injection attacks. |
| Allows inline scripts or styles with a specific hash (e.g., SHA-256) of the content. Prevents modification. |
| Allows specific inline scripts or styles and enables violation reports when they are blocked. |
The Generated CSP area will show the generated CSP based on all the directives and allowed sources you configure. The core Engaging Networks resources will automatically be included in your policy and will be shown in the generated CSP preview.
How to enable selected Content Security Policies
Once you have selected the Content Security Policy that is best for your organization and are ready to enabled the policy you can select 
. You will see an overlay to confirmed the policy should be enabled.
After choosing to enable the policy there will be a banner on the top right of the selected policy indicating it is enabled.
Testing a CSP
Once a policy has been enabled, an option to enable in Report Only mode will become available at the top of the CSP screen. Report only mode allows you to test your Content Security Policy without enforcing it. With the setting enabled, policy violations are logged in a browser's developer console, allowing you to identify potential issues while your site remains fully functional. You can use the developer console to view these logs and refine your policy during testing. Once testing is finalized, toggle the Report Only mode off to fully enforce the policy.
How to disable Content Security Policies
Once a CSP has been enabled, the button at the bottom will update. Select 
and then confirm you would like to disable on the overlay. This will remove the header from your pages and all assets will begin to load with no directives in place.
