Critical Update: Ensure Users Have Access to @AuraEnabled Methods

Winter ’21 is just around the corner and will include a critical update that could impact any page leveraging a custom component. As a Salesforce Admin, you’ve probably noticed this alert in your Security Alerts (Setup | Security | Security Alerts) and might have overlooked this. But because it involves permissions and user management, we want to make sure you can take action.
This update will be automatically enforced with Winter ’21 and steps should be completed by August 8, 2020.

What’s changing?

Currently, a user doesn’t need permission to access an Apex class containing an @AuraEnabled method. Following the “secure by default” approach, we added a critical update so that a user can access an @AuraEnabled Apex method only when the user’s profile allows access to the Apex class. In Winter ’21, we’ll automatically activate the critical update for all orgs. This critical update enforces user profile restrictions for Apex classes used by Aura and Lightning Web Components. Users will need to have permission in their profiles or permission sets to access an Apex class. Aura or Lightning Web Components that call @AuraEnabled methods contained in these Apex classes may fail to load or operate correctly.

What is @AuraEnabled and what uses it?

Apex uses @AuraEnabled to make methods accessible to custom web components. Previously, anyone who had access to the page could access the Apex functionality. With Winter ’21, the specific classes that offer that functionality will need to be enabled in order to provide access. This brings those classes in line with the same level of access as other Apex classes.

So, if you have pages or layouts that contain custom components (Aura or Lightning), those interfaces will only work correctly if the user’s profile includes the Apex class or they have a permission set which includes the class.

How to update profiles and permissions to access Apex with @AuraEnabled

In setup, you can add Apex classes to a profile under “Enabled Apex Classes Access”. For a permission set, you’ll see it under Apps as “Apex Class Access”. If you want to proactively find Apex classes that leverage @AuraEnabled, check out the open source tool @AuraEnabled Scanner. To install the tool, log in to the sandbox that you want to make the edits in. From there, go to:

https://<myDomain>.lightning.force.com/packaging/installPackage.apexp?p0=04tB0000000ZQHxIAO

Where <mydomain> is the prefix of the domain for your org. Once you’ve installed the package, go 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.

From there, you’ll have a list of Apex classes on the left that use @AuraEnabled. Clicking on one will allow you to update the profiles and permission sets that have access to the class.

Hopefully that makes it easier to scan through the classes that will be impacted by this update and give them the proper access.

A huge shoutout to David Cohen (@DavidsTwitThing) and Tyler Clark (@tylerclark) for creating @AuraEnabled Scanner.

One last thing…

At time of this publication, 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.