As part of an ongoing effort to make your org more secure, a critical update described in this release note will be enforced in the Winter ’21 release. This may affect your org, and you should take preventative action by August 8, 2020.

Some background

The @AuraEnabled annotation enables client and server-side access to an Apex controller method. Providing this annotation makes your methods available to your Lightning components (both Lightning Web Components and Aura components). Only methods with this annotation are exposed.

So what’s new?

Prior to the critical update, your Lightning components just worked. No extra steps necessary. With the update, you are required to specify which users can access Apex classes containing those @AuraEnabled methods. Those class permissions are granted via profiles or permission sets. Let’s take a look at what would happen using the ApexImperativeMethod Lightning Web Component from the LWC Recipes app once the critical update is activated.

The ApexImperativeMethod component calls an Apex method that queries and returns a list of ten contacts, and then simply displays those contacts. Here is a slimmed down version of the code — we’ll skip the HTML as it’s not relevant to our scenario, and we’ll make one minor addition: we’ll log any server-side error to the console.

Note the @AuraEnabled annotation on the getContactList method in the Apex controller.

Once the critical update is activated, if the running user does not have access to the ContactController class, the method call will fail and your app will unceremoniously crash. Let’s open up the Chrome developer console and see what gets logged.

Well, that couldn’t be much clearer! The user must be granted access to the ContactController class via their profile or a permission set.

But there are so many classes with @AuraEnabled methods! How can I keep track of who has access to what?

We want to make it easy for you to monitor all of your Apex classes with @AuraEnabled methods, understand which profiles and permission sets have access to what, and you’ll be able to add or remove those permissions as you see fit. To that end, we’ve whipped up the fully open source @AuraEnabled Scanner.

https://github.com/forcedotcom/AuraEnabledScanner

Simply install the unlocked package by visiting the following URL:
https://<myDomain>.lightning.force.com/packaging/installPackage.apexp?p0=04tB0000000d26UIAQ

, where <myDomain> is the name of your custom Salesforce domain. In a sandbox or scratch org, you can also push the @AuraEnabled Scanner code repository into your org using the IDE of your choice.

Then launch the app by heading on over to https://<myDomain>.lightning.force.com/c/AuraEnabledScanner.app. The @AuraEnabled Scanner requires you to have the AuraEnabled Scanner User permission set. You’ll be prompted to assign it if you haven’t done so.

The section 1 sidebar lists all the Apex classes in your org that contain one or more @AuraEnabled methods. A red flag next to a class means that not a single profile or permission set has been granted access to that class. You’ll want to check those first! Clicking on a class will populate sections 2 and 3. Section 2 highlights all the profiles and permission sets that currently have access to the selected class. You can modify those selections as you see fit. Finally, section 3 displays the code of the selected class, so you can get an idea of just what you’re granting access to.

Security is paramount to your organization. We hope the @AuraEnabled Scanner is one more helpful tool in your tool belt to help enforce it.

Important – At time of publication (August 3, 2020) there are some limitations affecting this update in Managed Packages:

• If the Managed Package is installed as “Install for All Users” then the Apex class permissions are provided implicitly to all users. Due to a known issue, the Apex class permissions can only be taken off with “Enhanced Profile Interface”.
• If the Managed Package is installed as “Install for Admins Only” then you need to make sure Apex class Permissions are provided.
  • For public classes, you need to use a Permission Set when “Enhanced Profile Interface” is turned off. Public class from Managed Package appears under Apex Access for Profiles only when “Enhanced Profile Interface” is turned on (known issue).
  • For global classes, you can either use a Permission Set (recommended) or a Profile.

About the authors

Tyler Clark is a Lead Platform Developer at Salesforce. He creates interactive applications that make Salesforce employees more productive. You can follow him on Twitter @tylerclark.

David Cohen is a Lead Platform Developer at Salesforce focusing on internal applications. One day he slipped, hit his head on the sink, and came up with the Schedul-o-matic 9000. David has only tweeted once and it was a retweet, but you can still follow him @DavidsTwitThing.