Configuring a Content Security Policy header

Important: You must have the Manage System Configuration action permission to make changes to the Content Security Policy header.

For greater security control, you can define your own Content Security Policy (CSP) header for Oracle Eloqua sites. This custom value is added to the HTTP header of all Oracle Eloqua landing pages, applications, and tracking domains for your account. Additionally, you can use the CSP header to specify where content can come from for these landing pages, applications, and tracking domains, such as only accepting content from specific domains. CSP helps protect against various attacks including Cross Site Scripting (XSS), data injection, and click jacking.

Warning: An incorrect content security policy can break functionality and lead to data loss. For example, if the domain you have included in the CSP header is spelled incorrectly, then your landing pages will not accept content from the domain with the correct spelling.

There are 4 steps to configuring your Content Security Policy header:

  1. Collecting the domains to include in the CSP header
  2. Navigating to the CSP header page
  3. (Optional) Testing the CSP header functionality
  4. Configuring your CSP header

Collecting domains for your CSP header

When configuring your CSP header, you need to consider which domains to include.

Default domains

Any content that comes from these domains needs to be included and allowed in your CSP header:

  • *.eloqua.com
  • *.en25.com
  • *.bluekai.com
  • *.oraclecloud.com

These are the default domains Oracle Eloqua needs for displaying your landing pages and the content within them, applications, and tracking domains. If your account is not currently branded, these domains most likely cover all of your use cases. The Configuring your CSP header section of this topic guides you through the proper formatting for adding these domains to your CSP header.

Branded domains, landing pages, application domains, and tracking domains

Tip: Contact My Oracle Support for assistance in determining which domains to include for this section.

Other than the default domains, any other domains you use for content in your landing pages, applications, and tracking domains must be included in your CSP header as well, such as any branded or First-Party-Cookie domains. For your branding, you need to include all branded landing page domains, branded image domains, branded application domains, and branded tracking domains.

To identify other domains to include in your CSP header:

  1. Navigate to Assets An image of the Assets icon, which is represented by a black pencil. > Email Setup > Email Defaults .
  2. Take note of any domains under Application Domain and Image Domain in the Brand Configuration section.

    These domains will need to be included in your CSP header.

    Note: The Brand Configuration section only displays domains tied to a brand. As there's a possibility that domains exist that are not tied to a brand for your account, this is not an exhaustive list of domains for your account.

  3. Navigate to AssetsAn image of the Assets icon, which is represented by a black pencil. > Website Setup > Microsites.
  4. Click on each microsite to open its Settings page.
  5. Take note of each microsite's subdomains in the Subdomain List section.

    These subdomains will need to be included in your CSP header.

  6. Contact My Oracle Supportfor a list of your account's tracking domains.

Custom content domains

Any custom content you use in your landing pages that comes from third party domains needs to be included in your CSP header, for example CDN domains for images, JavaScript, CSS, and any corporate domains.

Additionally, if you use images from a corporate domain in your landing pages, those images will not load if they are not allowed in your CSP headers. For example, if you're loading custom CSS from a corporate public website, then your corporate domain must be included in the CSP header.

Navigating to the CSP Header page

To navigate to the Content Security Policy Header Configuration page:

  1. Click SettingsAn image of the Settings menu icon, which is represented by a black cog..
  2. Click Security in the Users and Security area.
  3. Under Security Configuration, click CSP Header.

(Optional) Testing the CSP header functionality

Before fully configuring your CSP header, you can test the functionality using the following permissive configurations without risking breaking any existing landing pages.

To test your CSP header functionality:

  1. On the CSP header page, include the following in your CSP header:

    default-src * data: blob: filesystem: about: ws: wss: 'unsafe-inline' 'unsafe-eval'; script-src * data: blob: 'unsafe-inline' 'unsafe-eval'; connect-src * data: blob: 'unsafe-inline'; img-src * data: blob: 'unsafe-inline'; frame-src * data: blob: ; style-src * data: blob: 'unsafe-inline'; font-src * data: blob: 'unsafe-inline';

  2. Test using the following use cases:
    • Landing page renderings and tracking
    • Form submits from landing pages
    • Form visitor tracking
    • View Online Emails
    • Emails System Action links functionality

Configuring your CSP header

Once you've collected all the domains you need to include, you can start configuring the CSP header. If your account has no branded domains or custom content domains, you can copy and paste this CSP header into the Eloqua Content Security Policy Header Configuration text box.

To configure your CSP header if you have branded domains or custom content domains:

  1. Navigate to the Content Security Policy Header Configuration page.
  2. On the Content Security Policy Header Configuration page, add the default domains: default-src 'self' 'unsafe-inline' 'unsafe-eval' data: *.eloqua.com *.en25.com *.bluekai.com *.oraclecloud.com
  3. Append to this list all other landing page domains, branded domains, branded image domains, application domains, and branded tracking domains you collected from the Branded domains, landing pages, application domains, and tracking domains section.
  4. Append additional domains for custom content you use in your landing pages that come from third party domains, for example CDN domains for images, JavaScript, CSS, and any corporate domains.
  5. Click Save.
  6. Test the following use cases:
    1. Landing page renderings and tracking
    2. Form submits from landing pages
    3. Form visitor tracking
    4. View Online Emails
    5. Emails System Action links functionality

Accounts without branded domains or custom content domains

If your account has no branded domains or custom content domains, you can use the following CSP header for your Eloqua account.

Warning: It is extremely important that you confirm that you have no branded domains or custom content domains before saving this CSP header. Using only the following CSP header when your Eloqua account makes use of custom content domains or branded domains could result in broken landing pages, applications, or tracking domains. Learn more about configuring the CSP header if you have branded domains or custom content domains.

To add this CSP header to your Eloqua account:

  1. Navigate to the Content Security Policy Header Configuration page.
  2. On the Content Security Policy Header Configuration page, add the CSP header:
    default-src 'self' 'unsafe-eval' 'unsafe-inline' *.eloqua.com *.en25.com *.bluekai.com *.oraclecloud.com; script-src 'unsafe-inline' 'unsafe-eval' *.eloqua.com *.en25.com *.bluekai.com *.oraclecloud.com; img-src 'self' *.eloqua.com *.en25.com *.oraclecloud.com *.bluekai.com data:; connect-src 'self' *.eloqua.com *.en25.com *.bluekai.com *.oraclecloud.com;
  3. Click Save.
  4. Test the following use cases:
    1. Landing page renderings and tracking
    2. Form submits from landing pages
    3. Form visitor tracking
    4. View Online Emails
    5. Emails System Action links functionality

Learn more

Client security configuration

Landing pages

CSP header, header, CSP, content security policy, users and security, security configuration, security, http, landing page, tracking domain, application, Content-Security-Policy