Introducing New Content Security Policy Options for Lightning Communities

Trust has always been our #1 value here at Salesforce. We hold ourselves accountable for keeping your data secure at all times.

Community Cloud helps you build a digital experience for your customers, partners, and employees to interact with your company. Often, this requires bringing in resources from third parties (such as Google) in order to provide a comprehensive solution that fits your needs. With the Winter ‘19 release, we’ve added additional security options so that your new Lightning community has the flexibility to use the external resources you need.

The browser’s Content Security Policy (CSP) is a defense in-depth mechanism – it reduces the harm that malicious code can cause. CSP works by defining the “Content-Security-Policy” HTTP header, which instructs the browser what resources it can render or execute. It is meant to be used in addition to proper development patterns in order to mitigate potential damage from Cross-Site Scripting (XSS) attacks. To learn more about XSS, check out our Secure Coding Guidelines. We have, and will continue to provide, XSS protection for Salesforce components.

The combined policy

CSP for Lightning Communities is split into two parts. One part references the set of CSP directives shared with Lightning Experience (LEX). The second part is an additional set of script-src directives that are specific to each community.

Shared CSP directives

In LEX , we already support many CSP directives:

  • connect-src
  • frame-src
  • img-src
  • style-src
  • font-src
  • media-src

As of Winter ‘19 our new Lightning Communities CSP can use these directives as well.

This means that non-script resources included in a Lightning Community will need to have their URLs added to CSP Trusted Sites before going live with the new security options. For example, if you are loading images from a third-party host in your head markup, you will need to whitelist that host on the CSP Trusted Sites page. Entries in the CSP Trusted Sites whitelist can be applied to LEX, all Lightning Communities, or both.

You can modify your CSP Trusted Sites in Setup under Security > CSP Trusted Sites.

Each of the trusted sites that is declared in that UI is given a name (e.g. “GoogleMaps”) which may be referenced elsewhere in our platform. Each of the trusted sites is also persisted in the CSPTrustedSites entity.

Script Src

In addition to the other directives, we are now adding a way to include additional third-party scripts on the page. Script resources can’t be added to CSP Trusted Sites in LEX at this time.

This is a much more complex area, as much of the XSS protection offered by CSP requires you to implement strict CSP. Strict CSP defines tight constraints on the script-src directive so that only trusted scripts can be executed. However, in many business applications, it is not possible to implement strict CSP and include all of the third-party services necessary for your business. To give you flexibility, the Winter ‘19 release offers two new levels of security for Lightning Communities: strict CSP and relaxed CSP.

Strict CSP is the recommended option as it uses the most secure CSP we can provide. With strict CSP enabled, you won’t be able to load scripts from non-Salesforce domains.

Relaxed CSP allows both unsafe-inline and unsafe-eval, as well as the ability to provide a list of whitelisted hosts for serving scripts. We provide unsafe-inline and unsafe-eval because we know some common services, such as Google Tag Manager, require these to work properly.

Once you have added your external script sources, you can execute scripts from those third-party libraries in your community. Be careful to only whitelist sites that you trust. In addition, partners and packages on the AppExchange may also require you to whitelist their services in order to work correctly.

The new security tab

These new options are available on the new Security page of your Community Builder settings.


All Lighting Communities created before the Spring ‘19 release automatically use the lowest level of security to maintain backwards compatibility. This setting doesn’t use the shared CSP Trusted Sites, nor does it have defined JavaScript resources.

Existing customers can continue using their current security levels until Winter ‘20. We strongly encourage you to update your Lighting Community to one of our new options on your own before that option expires. You should be able to accomplish everything you need using the new security options.

See our Rollout plan and enforcement strategy for details.

Strict CSP

Strict CSP is the recommended and default setting for new Lightning Communities. In strict CSP, the non-script directives will follow what you allowed using CSP Trusted Sites. For the script-src directive, you won’t have access to external JavaScript resources.

Relaxed CSP

Relaxed CSP is the most flexible option. In relaxed CSP, like strict CSP, the non-script directives will follow what you have allowed using CSP Trusted Sites. But unlike strict CSP, for the script-src directive, you’ll be able to list script resources you want to make available. In the “Add Trusted Site” dialog, enter the new trusted endpoints you need to access.


If you later select Strict CSP, any trusted sites you have added will remain saved on your community, but will no longer be included in your policy.

Managed packages

In order to keep the trust of our vendors and partners, we must provide them the same level of control over their data and keep their data secure. We want to follow the principle of “secure by default.” This led us to a very hard question: What if a package developer only wants their code executed in a strict CSP environment?

We want to leave this choice to our partners. In order to follow the idea of “Secure By Default,” we will not be allowing Lightning components in relaxed CSP communities without the explicit consent of the package developer.

I know this sounds scary, but we expect most partners will be comfortable allowing their code in Lightning Communities without strict CSP, as packaged components would rarely contain any sensitive data about the partner’s business. In order to expose your packaged components to relaxed CSP communities, we’ve added a new Aura Interface: lightningcommunity:allowInRelaxedCSP

This must be present on every Lightning component that you want to make available in Relaxed CSP communities. Here is an example component.


<aura:component access="global" implements="forceCommunity:availableForAllPageTypes,lightningcommunity:allowInRelaxedCSP">
    <div>This is a correctly tagged component.</div>

It’s important to note that all child components must also be tagged. In the example below, you wouldn’t be able to use parent.cmp in strict CSP. This will be enforced starting Winter ‘20.


  <div>This is an empty, untagged component.</div>


<aura:component access="global" implements="forceCommunity:availableForAllPageTypes,lightningcommunity:allowInRelaxedCSP">

  <div>Tagged component using an untagged component.</div>



All components introduced during or after API v44 will need to include this tag in order to pass our component security validation.

Rollout plan and enforcement strategy

We understand that this is a lot to process. In order to give our developers and customers time to understand and prepare for these changes, we’re following a multi-release deployment plan.

Winter ‘19 (Oct 2018) Spring ‘19 (Mar 2019) Summer ‘19 (June 2019) Winter ‘20 (Oct 2019)
Lightning Communities Platform “Stricter CSP for Lightning Communities Critical Update” is removed
Strict CSP / Relaxed CSP communities functionality available (opt-in)
Component-level interface introduced for developers
All new Lightning Communities are defaulted to Strict CSP.
Introduce tooling for customer migration efforts (Security Meter, etc)
Enforcement Begins
Sunset support for ‘Grandfathered’ communities.
Enforcement of managed components in ‘Relaxed CSP’ communities.
Customer Action(s) Start working on migration plans to Strict CSP / Relaxed CSP. Configure & test security configurations in Sandbox, rollout to Prod Migrate all ‘Grandfathered’ communities to Strict CSP / Relaxed CSP.
Partner / Developer Action(s) Start adopting the component-level interface Start working on customer deployments / upgrades in Sandbox
Upload new package version to AppExchange (if needed)
All managed packages need to be updated, tested & deployed in Production orgs

You will see warning messages in the builder when selecting relaxed CSP, alerting you to any components that won’t pass component validation. When enforcement begins, any disallowed components will show the following message:

The component will not be displayed on the page. In addition, you’ll no longer be able to include components in Builder that do not pass component security validation and you won’t be able to save packages or custom components that introduce a component security violation. We can’t conduct static analysis on components created dynamically using JavaScript, such as those using $A.createComponent. Those components can be saved, but will still be validated at runtime.


We have provided new CSP options to Lightning Communities in order to enable you to build a more secure community, and we’ve provided a mechanism for our developers to protect their code. This will make Lightning Communities less vulnerable to XSS attacks and enhances the security controls for Salesforce developers and customers. We’re providing a roadmap to enforce these changes over the next several releases.


Here’s some further reading from all over the Web on what CSP is and why it is important:

About the authors

James Wonsever is a Lead Engineer on Community Cloud for four years since the inception of the Napili template. He has been involved with many parts of Community Cloud development.

Haris Ikram is a Product Manager on Community Cloud with experience on Lightning Community Builder, Partner Communities & Salesforce Files.

Harold Gross is a Staff Technical Writer on the Community Cloud team.

Leave your comments...

Introducing New Content Security Policy Options for Lightning Communities