In the Summer ’21 release, a mandatory security update will enforce access modifiers on Apex properties in Lightning component markup. In this post we’ll share what the security update entails and introduce a tool that helps you detect Apex properties that are potentially affected.
About the security update
Because Trust is our number one value, and because part of trust is knowing that we maintain high security standards, this security update is mandatory as of June 12. The update prevents access to private or protected Apex getters from Aura and Lightning Web Components. Let’s take a look at two examples that illustrate the impact of the update.
Example 1
In this first example, we have an Example1 Apex controller with a counter property that has a private getter. The controller exposes a getData() method annotated with @AuraEnabled. The method returns an instance of Example1 to Lightning components.
public class Example1 {
@AuraEnabled
public Integer counter { private get; set; }
@AuraEnabled
public static Example1 getData()
{
Example1 result = new Example1();
result.counter = 2;
return result;
}
}Once the security update is enforced, the Aura or Lightning Web Components that call Example1.getData() will no longer have access to the counter value and that may cause runtime errors.
Example 2
In this other example we have an Example2 Apex controller than fetches records and returns them wrapped in a PagedResult object instance:
public class Example2 {
@AuraEnabled
public static PagedResult getRecords()
{
PagedResult results = new PagedResult();
results.records = [...];
return results;
}
private class PagedResult {
@AuraEnabled
public Object[] records { protected get; set; }
}
}With the security update enforced, Lightning components no longer have access to PagedResult.records property because the getter is protected.
While these two examples may appear uncommon, you’ll want to inspect your Apex controllers for similar patterns so that you don’t experience runtime errors after the security update is enforced. Finding those patterns in a large code base isn’t trivial, so we’ve contributed a helper tool for that purpose.
Scanning for affected Apex properties
Instead of inspecting all of your Apex controllers one by one, we’re sharing a tool based on the Apex Language Server that scans your code base and reports potentially affected Apex properties. This tool is not officially supported by Salesforce, and it’s provided as-is without any warranties, but it will likely save you valuable time.
All you need to use the tool is a Java JDK or JRE version 11 or higher (this is already required for running VS Code). Then, simply download the JAR file from the project repository and run the following command in a terminal where PATH is the path of a parent directory that contains Apex .cls files:
$> java -jar apex-scan-1.2.0.jar PATHFor example, here’s how you can scan your entire force-app directory:
$> java -jar apex-scan-1.2.0.jar force-app
EnforcePrivateGetter.counter
EnforcePrivateGetter.PagedResult.pageSize
Scanned 1 Apex files and found 2 potential matches.In this example, the parser found one Apex file that contains two properties that may be affected by the security update. Thanks to the program output, you can see the fully qualified name of the properties and take appropriate actions if needed (remove the private or protected modifiers).
Because change introduced by the security update could ultimately affect your production, you should download the scanner tool and check your code today in preparation for the Summer ‘21 release on June 12 and the mandatory security update’s activation.
About the author
Philippe Ozil is a Principal Developer Advocate at Salesforce, where he focuses on the Salesforce Platform. He writes technical content and speaks frequently at conferences. He is a full stack developer and enjoys working on DevOps, robotics, and VR projects. Follow him on Twitter @PhilippeOzil or check his GitHub projects @pozil.
