LockerService Critical Update Activation

LockerService, which has been a critical update since Summer ’16, is enforced for all orgs in Summer ’17. However, to reduce the impact on existing components, we adjusted the activation process.
LockerService Enforcement Is Dependent on the API Version
LockerService is enforced for all Lightning components created after Summer ’17 (API version 40.0). LockerService isn’t enforced for components with API version 39.0 and lower, which covers any component created before Summer ’17.
Stricter Content Security Policy (CSP) Restrictions Aren’t Enforced
The stricter CSP restrictions, which mitigate the risk of cross-site scripting attacks, have been decoupled from LockerService and aren’t enforced in production orgs in Summer ’17. The stricter CSP changes are available only in sandbox and Developer Edition orgs and can be activated in two new critical updates, one for Communities and one for other contexts. The critical updates give you more time to update your code to work with stricter CSP.

LockerService Features Activated

LockerService enforces some security features and encourages best practices to make your code more supportable.

JavaScript ES5 Strict Mode Enforcement
JavaScript ES5 strict mode is implicitly enabled. You don’t need to specify "use strict" in your code.
JavaScript strict mode makes code more robust and supportable. For example, it throws some errors that would otherwise be suppressed.
A few common stumbling points when using strict mode are:
  • You must declare variables with the var keyword.
  • You must explicitly attach a variable to the window object to make the variable available outside a library.
  • The libraries that your components use must also work in strict mode.
For more information about JavaScript strict mode, see the Mozilla Developer Network.
DOM Access Containment
A component can only traverse the DOM and access elements created by a component in the same namespace. This behavior prevents the anti-pattern of reaching into DOM elements owned by components in another namespace.


It’s an anti-pattern for any component to “reach into” another component, regardless of namespace. LockerService only prevents cross-namespace access. Your good judgment should prevent cross-component access within your own namespace as it makes components tightly coupled and more likely to break.

Restrictions to Global References
LockerService applies restrictions to global references. LockerService provides secure versions of non-intrinsic objects, such as window. For example, the secure version of window is SecureWindow. You can interact with a secure wrapper in the same way as you interact with the non-intrinsic object, but the secure wrappers filter access to the object and its properties. The secure wrappers expose a subset of the API of the underlying objects.
The LockerService API Viewer shows the DOM APIs exposed by LockerService. The API Viewer app lists the API for SecureDocument, SecureElement, and SecureWindow.
The current UI for the API Viewer is unpolished. Bear with us while we improve it. There’s a lot of information but the main takeaway is that a background green color means that the DOM method is supported.
Access to Supported JavaScript API Framework Methods Only
You can access published, supported JavaScript API framework methods only. These methods are published in the reference doc app at https://<myDomain>, where <myDomain> is the name of your custom Salesforce domain. Previously, unsupported methods were accessible, which exposed your code to the risk of breaking when unsupported methods were changed or removed.

Disabling LockerService for a Component

When a component is set to at least API version 40.0, which is the version for Summer ’17, LockerService is enabled. LockerService is disabled for any component created before Summer ’17 because these components have an API version less than 40.0. To disable LockerService for a component, set its API version to 39.0 or lower.

Component versioning enables you to associate a component with an API version. When you create a component, the default version is the latest API version. In Developer Console, click Bundle Version Settings in the right panel to set the component version.

LockerService is enabled for a component or an application purely based on component version. The containment hierarchy within an application or a component doesn’t factor into LockerService enforcement.

Let’s look at an example where Component A contains Component B. If Component A has API version 40.0, LockerService is enabled. If Component B has API version 39.0, LockerService is disabled for Component B even though it’s contained in a component, Component A, that has LockerService enabled.

For consistency and ease of debugging, we recommend that you set the same API version for all components in your app, when possible.

LockerService Setting for Managed Packages Has Been Removed

In Spring ’17, there was a separate setting to control whether LockerService was enforced for components installed from a managed package. This Enable LockerService for Managed Packages setting has been removed from the Lightning Components page under Setup.

Components installed from a managed package are treated the same as any other component and are subject to LockerService restrictions.

New AppExchange security reviews and periodic re-reviews will require components to be version 40.0 or higher so that LockerService is enabled. The version requirement ensures that components installed from managed packages follow the security best practices that are enforced by LockerService.

What Does LockerService Affect?

LockerService enforces security and best practices for custom Lightning components you use in:
  • Lightning Experience
  • Salesforce1
  • Lightning Communities
  • Standalone apps that you create (for example,
  • Any other app where you can add a custom Lightning component, such as Salesforce Console in Lightning Experience
  • Lightning Out
LockerService doesn’t affect the following except for usage of Lightning components in Visualforce in these contexts:
  • Salesforce Classic
  • Visualforce-based communities
  • Any apps for Salesforce Classic, such as Salesforce Console in Salesforce Classic