An update is coming in the
Criticality: By taking no action, your customers may experience application security exceptions, potentially disrupting their business processes, which can erode their trust in your application.
Feature Enforcement: Release weekends for Winter '21: September 18, October 9, October 16
Testing: Critical Update behavior can only be tested in Winter '21 pre-release orgs (avail. Aug 21, 2020) or Sandbox Preview orgs/Scratch Orgs (avail. Sept 11, 2020)
Distribution: Publish patch releases for all of your supported application versions to allow customers to update their existing installations. Consider using push upgrades to distribute a patch release with the security update.
Support: Plan to support customers who need to apply security updates manually.
Prior to this security update, apex class access was implicit. If the running user had access to a component, they were also granted access to its supporting apex controller class. After this security update is enforced, when a user attempts to call a method on an apex class that they do not have explicit access to, they will be denied access, and an error will be output to the browser console.
Since managed source code is hidden from the subscriber in their org, these classes with @AuraEnabled methods need to be identified by your development team in your source code because the subscriber will not be able to easily identify classes within your application which need additional access granted.
It is important to test all supported versions of your managed application during the pre-release/sandbox preview window and distribute patch releases prior to the first Winter '21 release weekend (September 18, 2020) to ensure that your customers’ business processes are not disrupted by the Winter '21 release.
The recommended approach is to update your application's permission sets, enabling access to the apex classes that expose @AuraEnabled methods to Aura and LWC components.
The updated permission sets can be distributed in patch releases and delivered to your customers through a package installation link or push upgrades.
Release Notes & Manual Approach
It is recommended to document the changes involved in granting permissions to your application classes in the event that your customers need to apply the additional access manually. Manual implementation steps by the admin may be required in controlled or validated environments or if the customer has cloned your application permission sets.
The documentation of the necessary changes can also be used by your customer support teams to confirm or adjust the configuration of the customer's environment and ensure that the appropriate access has been granted when troubleshooting.
The application may have been installed by the subscriber org's admin selecting the security option of "Install for All Users", which grants access to all of the application classes to all users. However, this mechanism cannot be relied upon to provide user access in all cases. Any installation in which the administrator chose the option "Install for Admins Only" or "Install for Specific Profiles…" will not be granted this implicit access to the packaged classes. In these cases, access to the classes must be granted explicitly using permission sets or profiles.
If your application includes Profile Settings, these settings are only applied during the initial installation of the application in the subscriber's org, and any additional access granted in your application's profile settings will not have an effect on an existing installation, only new installations.
Since profile settings are only applicable to the initial package installation, if you are solely reliant on included profiles for granting application permissions, you should consider adding permission set(s) to your next major application release to simplify future revisions to your application's security model.
Note: A patch release cannot include a new permission set, but can update existing permission sets.
There are a few tools available to quickly identify all of the classes in your application, which contain AuraEnabled methods. After identifying the classes, your application's permission sets and profiles can be updated accordingly to grant the necessary access.
An unlocked package that can help identify classes that need permission granted to existing permission sets and profiles.
Do not install this application directly in your packaging org. For safety, install the AuraEnabled Scanner application in a separate org which contains the unmanaged source code and perform the scan in that org. The fixes can then be applied to the packaging org.
Salesforce blog post "Breezing Through the Upcoming @AuraEnabled Critical Update".
Developer Console's Search in Files feature
In the packaging org, open the Developer Console and from the Edit menu select Search in Files. From there, you can search for AuraEnabled and view a list of classes for which your application's permission sets and profiles may need to enable access.
Your favorite IDE or source control system's search feature
Leverage the search functionality within your favorite IDE or your source control system with your source code to identify any classes which may need to have access granted.