📢 Attention Salesforce Certified Trailblazers! Maintain your credentials and link your Trailhead and Webassessor accounts by April 19th. Learn more.
close
Start tracking your progress
Trailhead Home
Trailhead Home

Get Started with Lightning Security

Note

Note

Attention, Trailblazer!

Salesforce has two different desktop user interfaces: Lightning Experience and Salesforce Classic. This module is designed for Lightning Experience.

You can learn about switching between interfaces, enabling Lightning Experience, and more in the Lightning Experience Basics module here on Trailhead.

Learning Objectives

After completing this unit, you’ll be able to:

  • Describe how developing secure Lightning components differs from developing secure Visualforce pages.
  • Summarize security protections enforced by Lightning Locker.
  • Sign up for a special Security Testing Developer Edition org.

Lightning Security Architecture

We’re pretty excited about Lightning. It’s the future of the Salesforce platform, and offers several improvements over Visualforce. There are a lot of changes under the hood that affect how we provide the best user experience, and how we secure customer data.

In this module we show you how to take advantage of the security we built into Lightning. The material here builds on concepts in the Develop for Lightning Experience trail. If you haven’t yet completed the modules in that trail, go there first.

Note

Note

As of the Spring ‘19 release (API version 45.0), you can build Lightning components using two programming models: the Lightning Web Components model and the original Aura Components model. Lightning web components and Aura components can coexist and interoperate on a page.  This content covers Aura components. 

For more information about Lightning web components, see Introducing Lightning Web Components.

In the Lightning Component framework, the UI and components communicate with each other by responding to events. Components can talk to the server and to other components. Each component is responsible for its own security within the Lightning environment. This means everyone who creates or maintains a component must understand how to write secure code for Lightning.

Aura Versus Visualforce

Aura and Visualforce handle security in different ways. If you’ve done a lot of work in Visualforce, it helps to know about these differences. From a security perspective, there are three main differences between Visualforce and Aura: shared resources, encapsulation, and data security.

Shared Resources 

In Visualforce, you build complete pages, and it’s difficult to reuse material on a page. In Aura, the basic building blocks are components, which are reusable and easily replaceable. An Aura application that uses a component can instantiate that component several times within a page. 

In an Aura application, all components in the Lightning user interface load into the same page so they can be reused. These components share key resources like the global window and JavaScript interpreter. Be careful about using functions that take control of the entire window, such as JavaScript alerts and global calls, or writing code that takes a great deal of JavaScript processing, as it will affect other components in the same window.

Encapsulation 

Salesforce doesn’t support code that attempts to modify components on a page outside the Aura framework. Anything that changes data in a component without using its attributes, methods, or Aura framework methods is unsupported. This kind of code can cause instabilities or vulnerabilities in your app.

Data Security

Visualforce enforces the active user’s CRUD and FLS permissions when a page renders a Salesforce object. Aura doesn’t do any client-side authorization, so it doesn’t respect these permissions. The following code shows data to all users, even those who aren’t authorized to see it.

<b>Hello <i>{!v.User.FirstName}</i>.</b>


When you write Aura components,  do your own data access checks in your Apex controllers.

Securing Component Interfaces

Aura components are very powerful. They can do easy things like displaying data, or they can do more complicated things like creating and modifying records. Components interact with each other using  Aura attributes and methods. Aura lets you control who can access the attributes and methods you write. We’ll cover access control in a later unit—for now, we just want you to know that it’s there for you to use. 

If you want to do a server-side operation, you write an Apex handler for that action. You do this by writing a function in Apex with the @AuraEnabled annotation. To prevent another component from calling your server-side Apex function, use standard access control (CRUD/FLS/Sharing) for the user in every @AuraEnabled method.

Write Components That Do Specific Things

You know you must secure each of your components against malicious input. There are a lot of baddies out there, so you can’t trust any input the component handles. But how do you identify malicious input? 

Ask yourself: Does your component have a specific purpose? What do you know about the input it handles? How is it used? The more you can describe what good input looks like, the better you can protect against anything that doesn’t match that description. 

Overly general components are difficult to secure. If a component does something really broad like “render input,” you can’t tell whether that input is good or bad. Here’s an example of a general component.

<aura:component access="global"> 
<aura:attribute name="iframeURL" type="string" access="global" /> 
<iframe src="{!v.iframeUrl}" /> 
</aura:component>

Where is the iframe coming from? If you knew where it was supposed to originate, you could whitelist its domain and block frames from other sources. But if another developer decided to reuse your general component to render something else, your whitelist might not work for the new use case. 

Create components for a specific use case, rather than general components that do it all. Specific components have security requirements in their specification—general components don’t tell you how to secure against bad input. 

Lightning Locker

Lightning Locker is Salesforce’s security architecture for Aura components. Lightning Locker isolates individual Aura components in their own containers so they can’t interact with one another directly except through tools provided by the framework, like Aura attributes or events. 

This component-level isolation protects your app from malicious components written by other developers, and it allows only interactions that you explicitly declare. 

Lightning Locker also provides explicit security measures for your components, such as a Content Security Policy (CSP) to help mitigate cross-site scripting (XSS) attacks and resource restrictions to ensure that images and scripts load securely.

Lightning Locker has opinions about software engineering, too. It makes your code easier to support by allowing access only to supported APIs and hiding unpublished framework internals. Lightning Locker also enforces strict mode on all JavaScript code to minimize code-related drama. After all, isn’t your job interesting enough?

JavaScript in Strict Mode

JavaScript code that runs in a browser can access a user's private information. To protect this information, Lightning Locker requires you to use ECMAScript (ES5) strict mode, and enforces it in your code. This mode makes it easier to write secure JavaScript. A few code tweaks to comply with ES5 can substantially reduce the need for checking data at runtime.

Here’s a simple example of how strict mode prevents JavaScript from traversing the call-stack and modifying other functions. Without strict mode, the following function would have returned the name of the function that called primaryFunction(). 

JavaScript code:

function primaryFunction() { 
  'use strict' 
  console.log("The function calling the current method is: “+ primaryFunction.caller.name); 
} 
function callerFunction() { 
  return primaryFunction(); 
} 
callerFunction();

Output:

  Uncaught TypeError: 'caller' and 'arguments' are restricted function properties and cannot be accessed in this context. 
  at primaryFunction (<anonymous>:3:72) at callerFunction (<anonymous>:6:10) at <anonymous>:8:1

Strict mode restricts access to several other entities. When it is enforced, you can no longer reference the window object through the JavaScript variable this, for example. These restrictions eliminate a lot of potential security vulnerabilities. 

Content Security Policy (CSP)

Salesforce’s content security policy disallows inline JavaScript and restricts the JavaScript eval function to the global scope in your code. This helps secure your components against attacks such as cross-site scripting. Fire up the Salesforce Lightning CLI tool and search your code and its dependencies to see if anything uses these features. Remove any calls that you can find. If one of your libraries uses inline JavaScript or eval in local scope, you have to modify it, or look for replacement libraries that work under CSP.

Note

Note

CSP isn’t enforced by all browsers. For example, Internet Explorer 11 doesn’t use it. For a list of browsers that enforce CSP, see Can I use...Content Security Policy.

Learn with a Developer Edition Org

You use a hands-on org to work through the challenges on Trailhead. This org is a safe environment where you can practice fixing security vulnerabilities in Aura components. For all of the modules in this trail, we’ve created a special org: the Kingdom Management developer org. This org contains several vulnerable applications, so you can spend your time honing your security skills instead of writing your own vulnerable Force.com code.

The object of each challenge is simple: identify the vulnerabilities and fix them. Use a Kingdom Management developer org for these challenges—you can’t use an existing Developer Edition org or a Trailhead Playground org for any of the modules in this trail.

Here’s how to sign up for a Kingdom Management developer org.  

  1. Go to the custom sign-up page for the Kingdom Management developer org.
  2. Fill out the form using an active email address and click Sign Me Up.

    Sign up page screenshot




  3. Check your email for an activation request.
  4. Click the link in the email, and complete your registration by setting a new password and challenge question.

When you have your Kingdom Management developer username and password, you’re ready to learn how to protect your users and data with application security.

Note

Note

The code in the Kingdom Management application is vulnerable to certain attacks. These vulnerabilities can’t do any damage in a Developer Edition org, but they can wreak havoc if they get into a production Salesforce environment. Use the Kingdom Management application only to learn about security and vulnerabilities.

In the next unit, we take a look at how to use HTML/Aura markup to create secure Lightning components.

Resources

Aura Framework

What is the Lightning Component Framework?

Introducing Lightning Locker for Lightning Components

Lightning Aura Components Developer Guide

ECMAScript strict mode

Understanding Cross-Site Scripting

ECMAScript 5

retargeting