Content Security Policy (CSP) directives

If you are using the Content Security Policy (CSP) for your Adobe Target implementation, you should add the following CSP directives when using at.js 2.1 or later:

Frequently Asked Questions (FAQs)

Consult the following FAQs about security policies:

Do Cross Origin Resource Sharing (CORS) and Flash Cross-domain policies present security issues?

The recommended way of implementing the CORS policy is to permit access to only trusted origins that require it via an allowlist of trusted domains. The same can be said for the Flash Cross-domain policy. Some Target customers are concerned about the use of wildcard characters for domains in Target. The concern is that if a user is logged in to an application, and visits a domain allowed by the policy, any malicious content running on that domain can potentially retrieve sensitive content from the application and carry out actions within the security context of the logged in user. This situation is commonly referred to as Cross-Site Request Forgery (CSRF).

In a Target implementation, however, these policies should not represent a security issue.

“adobe.tt.omtrdc.net” is an Adobe-owned domain. Adobe Target is a testing and personalization tool and it is expected that Target can receive and process requests from anywhere without requiring any authentication. These requests contain key/value pairs that are used for A/B testing, recommendations, or content personalization.

Adobe does not store Personally Identifiable Information (PII) or other sensitive information on Adobe Target edge servers, to which “adobe.tt.omtrdc.net” points.

It is expected that Target can be accessed from any domain via JavaScript calls. The only way to allow this access is by applying “Access-Control-Allow-Origin” with a wildcard.

How do I allow or prevent my site from being embedded as an iFrame under foreign domains?

To allow the Visual Experience Composer (VEC) to embed your website in an iFrame, the CSP (if set) must be changed on your web server setting. Adobe domains must be whitelisted and configured.

For security reasons, you might want to prevent your site from being embedded as an iFrame under foreign domains.

The following sections explain how to allow or prevent the VEC from embedding your site in an iFrame.

Allow the VEC to embed your site in an iFrame

The easiest solution to enable the VEC to embed your website in an iFrame is to allow *.adobe.com, which is the broadest wildcard.

For example:

Content-Security-Policy: frame-ancestors 'self' *.adobe.com

As in the following illustration (click to enlarge):

{width="600" modal="regular"}

You might want to allow only the actual Adobe service. This scenario can be achieved by using *.experiencecloud.adobe.com + https://experiencecloud.adobe.com.

For example:

Content-Security-Policy: frame-ancestors 'self' https://*.experiencecloud.adobe.com https://experiencecloud.adobe.com https://experience.adobe.com

As in the following illustration (click to enlarge):

{width="600" modal="regular"}

The most restrictive access to a company’s account can be achieved by using https://<Client Code>.experiencecloud.adobe.com https://experience.adobe.com, where <Client Code> represents your specific client code.

For example:

Content-Security-Policy: frame-ancestors 'self' https://ags118.experiencecloud.adobe.com https://experience.adobe.com

As in the following illustration (click to enlarge):

{width="600" modal="regular"}

Prevent the VEC from embedding your site in an iFrame

To prevent the VEC from embedding your site in an iFrame, you can restrict to “self” only.

For example:

Content-Security-Policy: frame-ancestors 'self'

As shown in the following illustration (click to enlarge):

{width="600" modal="regular"}

The following error message is displayed:

Refused to frame 'https://kuehl.local/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors 'self'".