Lightning Security

General Lightning Security Considerations

Third-party Lightning components and apps operate in a special domain (lightning.force.com or lightning.com) that's shared with Salesforce-authored Lightning code -- in particular, setup.app, which controls many sensitive security settings. Visualforce applications, by contrast, are served from a different domain (force.com) that isn't shared with Salesforce code. Because Lightning code shares the same origin as Salesforce-authored code, increased restrictions are placed on third-party Lightning code. These restrictions are enforced by Lightning Locker and a special Content Security Policy. There’s also additional scrutiny in the AppExchange security review.

When developing Lightning apps, ensure that the stricter CSP setting is enabled. Org admins should enable this setting to protect the org's security controls from vulnerabilities in custom Lightning components. Develop and test your code with stricter CSP enabled in order to ensure compatibility. Note that stricter CSP is enabled by default beginning with Summer '18, but not in orgs created previously.

Content Security Policy for Lightning Components

Lightning components are currently subject to a Content Security Policy (CSP) with the following directives. See CSP Directives for more information.

Additional Restrictions For JavaScript in Lightning Components

In addition to CSP directives, secure components also meet the following restrictions.

<div onmouseover=”myFunction”>foo</div>

<div onmouseover="{!c.myControllerFunction}">foo</div>

<div onmouseover={myComponentFunction}>foo</div>

You should also be familiar with the restrictions listed in Security with Lightning Locker.

When you submit a Lightning component or app for security review, include all source JavaScript files in static resources, as we cannot review minified code directly. Failure to do so delays the review of your components until we get the appropriate source files. This also applies to sources that compile to JavaScript.

Access Control in Apex Controllers and Supporting Classes

When Lightning components invoke server-side controllers, the developer must ensure that the server-side read/write operations don’t subvert the organization's security policy as set by the user's profile and sharing permissions. All access control enforcement must occur server-side, because the client is under the control of the attacker. Fortunately you can ensure that your server-side code is safe to use with Lightning components by taking some additional steps when writing your Apex classes.

Sharing in Apex Classes

public class ExpenseController() {  //Unsafe
    
    @AuraEnabled
    public static String getSummary() {
        doPrivilegedOp() //should not be here  
    }
}

public with sharing class ExpenseController() { //safe 

    @AuraEnabled
    public static String getSummary() {
        HelperClass.doPrivilegedOp()
     }
}

public without sharing HelperClass() { //safe, not a controller and limited functionality

    protected static String doPrivilegedOp() {
        //calculate roll-up field here
    }
}

Avoid ambiguous sharing policies that make auditing difficult, particularly in large apps with complex control flows. Write apps in such a way that an auditor who looks at a class that performs a database operation can quickly and accurately determine if the database operation respects user permissions. All global classes, classes that expose webservices, or allow for remote invocation (such as Aura Enabled classes and remote action classes) must always use the with sharing keyword. The exception is for controller classes in sites, including Experience Cloud sites, where a with sharing policy could force the granting of excessive permissions to guest users.

CRUD/FLS Enforcement

public with sharing class ExpenseController {

     //ns = namespace, otherwise leave out ns__  
    @AuraEnabled
    public static List<ns__Expense__c> get_UNSAFE_Expenses() {   //vulnerable
        return [SELECT Id, Name, ns__Amount__c, ns__Client__c, ns__Date__c, 
            ns__Reimbursed__c, CreatedDate FROM ns__Expense__c];
     } 

	@AuraEnabled
	public static List<ns__Expense__c> getExpenses() { //safe
        String [] expenseAccessFields = new String [] {'Id',
                                                       'Name',
                                                       'ns__Amount__c',
                                                       'ns__Client__c',
                                                       'ns__Date__c',
                                                       'ns__Reimbursed__c',
                                                       'CreatedDate'
                                                       };


        // Obtaining the field name/token map for the Expense object
        Map<String,Schema.SObjectField> m = Schema.SObjectType.ns__Expense__c.fields.getMap();

        for (String fieldToCheck : expenseAccessFields) {

          // Check if the user has access to view field
          if (!m.get(fieldToCheck).getDescribe().isAccessible()) {

               //also pass error to client
               throw new System.NoAccessException()

               //included to quiet editor
               return null;
            }
         }
 
         //now it is safe to proceed with call
         return [SELECT Id, Name, ns__Amount__c, ns__Client__c, ns__Date__c, 
                     ns__Reimbursed__c, CreatedDate FROM ns__Expense__c];
    	       
       } 
 }

Field Validation Concerns

For purposes of threat modeling, the client is under the control of the attacker, therefore you cannot rely on client-side field validation to sanitize data written to the server. Client-side field validation has an important usability role -- avoiding round trips for normal (non-malicious) users. Nevertheless, if you require field-level validation of your sObject data model, then this must be performed with triggers. Note that validation in the Aura-enabled server-side controller is also insufficient as users can use the SOAP/REST API to modify objects directly, bypassing the Apex Controller as well as the UI.

Object Validation Concerns

When Aura enabled methods receive objects as input types, you must validate the fields within those objects, since any fields could be set by the client. Here’s a typical vulnerable example.

@AuraEnabled
    public static Account insertAccount(Account a){
        // We expect only Name to be set
        if(Schema.SObjectType.Account.fields.Name.isUpdatable()){
            insert a; // <== problem: if Account "a" includes other fields  
                      // or custom fields they will also be set.
            return a;
        }
        
        return new Account();
    }

To do this, you must iterate through all populated fields and check FLS on those fields.

@AuraEnabled
    public static Account respectFLS(Account a){
        Map<String, Schema.SObjectField> fieldMap = Schema.SObjectType.Account.fields.getMap();
        Map<String, Object> fieldsToValue = a.getPopulatedFieldsAsMap();
        for(String fieldKey : fieldsToValue.keySet() ) {
            // if this populated field is not accessible, throw an error 
            if(! fieldMap.get(fieldKey).getDescribe().isUpdateable()) {
                throw new SecurityException('Invalid fields');
            }
        }
        insert a;
        return a;
    }

Cross Site Request Forgery

({
    doInit: function(cmp) {
        var action = cmp.get("c.updateField"); //vulnerable to CSRF
        [...]
        $A.enqueueAction(action);
       },
    handleClick: function(cmp, event) {
        var action = cmp.get("c.updateField"); //not vulnerable to CSRF
        [...]
        $A.enqueueAction(action);
       } 
})

The key is that the DML operation not be performed without an event stemming from human interaction, such as a click. CSRF only applies to server-side DML operations, not operations that update client-side component attributes.

Cross Site Scripting

<div>Here is a <b> {!v.myvalue} </b> bold value</div> <!-- always safe-->
<div title="{!v.myvalue}">a div</div>   <!-- always safe-->
<div title="{!v.myvalue}">a div</div>   <!-- always safe-->
<div {!v.myvalue}>a div</div>   <!-- will not compile-->
<div title="Here is a {!v.myvalue}">a div</div>   <!-- will not compile -->
<div title="{!'Here is a ' + v.myvalue}">a div</div>   <!-- always safe-->

Because of this, no encoding is ever performed by the framework when rendering component markup, nor are any encoding functions provided by the framework.

<a href="{!v.foo}">click</a> //unsafe: foo=javascript:..
<iframe src="{!v.foo}"/> //unsafe: foo=javascript:..

The following is a partial list of unsafe combinations of tags and attributes that should be avoided, if possible within lightning component markup  in order to avoid assigning unsafe values to lightning attributes:

This is only a partial list. See html5sec.org for more information about possible unsafe attributes. Of the above unsafe constructions, two are commonly used in component markup, namely anchor tags as well as style tags. There are several options for sanitizing these attributes.

<a href="{!v.foo}">click</a> //unsafe: foo=javascript:..
<a href="{!'/' + v.foo}">click</a> //forces scheme to be https or http

The same procedure can be used to control other URIs.

If you must handle both absolute and relative URIs, another option is to mark the attribute as private (for example if you are setting it in your code and are not setting it externally).

Alternately if you cannot mark the attribute as private and must set it in component markup (rather than a custom renderer) you will need to sanitize the attribute yourself with an onChange event:

<aura:component>
    <aura:attribute name="attr" type="String" />
    <aura:handler name="change" value="{!v.attr}" action="{!c.sanitizeUrl}" />
    <aura:handler name="init" value="this" action="{!c.sanitizeUrl}" />
    <a href="{!v.attr}">click here</a>
</aura:component>

({ 
    sanitizeUrl : function(cmp, event, helper) {
        var el = document.createElement('a'); 
        el.href = ('getParam' in event) ? event.getParam('value') : cmp.get('v.attr');    
        if (el.protocol !== 'https:') { 
            cmp.set('v.attr', ' ');
        }
})

Note that the scheme is parsed by the browser rather than with string handling functions. Also note that both the init and change events must be filtered to make sure that only controlled schemes are rendered or re-rendered in your component's markup.

Because the binding between component markup and lightning attributes is automatic, unless you intercept value changes, your code cannot sanitize attributes set from outside your component. Moreover, it is a bad practice to rely on the code that instantiates or interacts with your component to pass you safe values. Relying on the caller to give you data that is safe creates a security dependency between the internal structure of your component and all of the possible callers. In large applications, this typically results in failure to sanitize some input.

Because the above sanitization technique is heavyweight, it is preferable to use only relative URLs in component markup, or to use only private attributes (for example, if the URL is pulled from a URL type on the server).

For style tags, CSS as a language is difficult to sanitize in such a way as to prevent style injection. Moreover, the 'type' fields within lightning attributes are not enforced -- e.g. field marked 'Boolean' may well contain strings, etc. Therefore it is a bad practice to pass attribute values to style tags. Instead use tokens, private attributes, or javascript to manage style changes.

rerender: function(cmp, event, helper) {
    var el = cmp.find("xyz").getElementById("abc");
    var myattr = cmp.get("v.myattr");
    el.innerHTML = "<b>" + myattr +"</b>"; //unsafe
    el.innerHTML = "<b>" + cmp.helper.secureFilters.html(myattr) +"</b>"; //safe

and place the secureFilters code into your helper. Alternately, use an html encoding function that performs the same substitution operations as secureFilters' html() function.

If in the future, encoding functions are provided natively by the framework, this section will be updated with new instructions. Don’t roll your own encoding functions.

Don’t rely on CSP to prevent XSS, as the presence of CSP policies will depend on how your component is surfaced and what the organization's policies are, which is subject to change at runtime. Additionally, CSP will not protect your code from html or style injection.

For more information about general XSS issues, see our Secure Coding Guidelines.

Arbitrary Redirect

When redirecting to a third-party side:

1. Use HTTPS.
2. Ensure that the domain is hard coded into the source or stored in a custom setting. Storing the domain in a custom object field is not considered sufficient protection.

Secret Inputs

In Visualforce, user password entry should be performed with <apex:inputSecret> tags. The Lightning equivalent for this is the <ui:inputSecret /> component.

Third-Party Frameworks

Check out this blogpost about using third-party frameworks within Lightning Locker.