Secure Custom Metadata Types and Custom Settings in Winter ’20

At Salesforce we take security seriously, and we are always looking for different ways to ensure that our features are secure so the data in your org is protected. When we first introduced custom metadata types and custom settings, they were intentionally made accessible to anyone with API access. This allowed customers to use these types of objects to broadly drive forward the different aspects of their app and org configuration. As the Salesforce Platform becomes more powerful, the complexity of the solutions that our customers build expands as well. With this in mind, we are dedicated to providing improved tools that customers can use to control who has access to potentially sensitive configuration objects. We want to ensure those can be secured by default so that Admins don’t have to worry. This is why in Winter ’20 we are introducing some critical updates and a set of new features to make custom settings and custom metadata types more secure. Take a look at the critical updates that are scheduled for enablement with the rollout of the Spring ’20 release:

• Starting Spring ’20, users without the “Customize Application” permission will not be able to access custom metadata types and custom settings outside of System context (for example: Apex code).
• Administrators can enable this critical update in the Winter ’20 release to analyze the impact.
• In Winter ’20, administrators can grant access to a specific custom metadata type to a desired profile or permission set to allow direct access outside of Apex code/System context.
• For custom settings, administrators now can add the “View All Custom Settings” permission to a profile or permission set to allow direct access.

How to prepare for the upcoming critical updates

There are several things you can do today to prepare for the upcoming critical updates. To evaluate these critical updates and minimize the impact, perform these steps in sandbox orgs first before moving to production. We encourage everyone to follow these steps:

1. Review the custom settings and custom metadata types in your org. Do any of them require direct access from outside of Apex code/System context by users without the “Customize Application” permission?
2. Grant read access to specific custom metadata types to the desired user profile or permission set, or assign them the “View All Custom Settings” permission to enable access to custom settings.
3. Enable critical updates. You can do this via the Critical Update page or on the Schema Settings page.

Once you follow these steps, verify that everything is functioning as expected. As always, we recommend testing any changes in a sandbox environment first before applying them in production.

VisualForce Pages and System Mode

It’s important to be aware of the behavior of Apex and Visualforce when reviewing custom settings and custom metadata. In Salesforce, all Apex code is run in system mode. In system mode, Apex code has access to all object and field permissions. This is to ensure that the code won’t fail to run because of hidden fields or objects for a specific user. The standard mode of execution for Visualforce is to run in user mode.

Consider the following scenario:

1. Apex loads a record that is a row included in a variable such as MySetting__c.
2. What Visualforce displays is MySetting__c.MyPath__c.
3. Access checks are run when the page is loaded.
4. However, the checks are not run in system mode, which is the standard Visualforce behavior. What this means is that a user without custom setting permissions won’t be able to display the Visualforce page, because Visualforce is reinitiating the access check.

Rather than grant permissions to users, the workaround for this type of Apex and Visualforce scenario is to create a String for each object that you need to pass through, or create a wrapper class, rather than assign a MySetting__c variable and then rendering mySetting.Path__c mySetting.Name.

How to achieve even more security with protected custom metadata types

You can grant access to custom metadata types and custom settings to protect them, which provides additional security benefits when these objects are released as a managed package. Protected custom metadata types and custom settings are not accessible from outside of Apex code that is a part of the same package, and administrators in the subscriber org where the managed package is installed can’t see them.

It’s important to understand that protection only works in the context of a managed package. So if you simply mark a custom metadata type as protected in your org, it would not change anything.

Summary

Spring ’20 is going to change the access model for custom metadata types and custom settings. It’s essential to evaluate the impact of these critical updates prior to the rollout to identify risks and take the necessary steps in advance to mitigate them. In Winter ’20, we are providing a new permission for custom settings (“View All Custom Settings”) and the ability to grant access to a particular custom metadata type for a particular profile or permission set.

You can also learn more about best practices on how to manage application secrets in Salesforce in this Trailhead module!

For an overview presentation of these critical updates, check out the video below!

Additional Resources

• Require Customize Application Permission for Direct Read Access to Custom Metadata Types (Critical Update)
• Grant Access to Custom Settings on Profiles and Permission Sets After Restricting Org-Wide Access (Critical Update)
• Trailhead module – Secure Secret Storage
• Custom Metadata Types – Trailblazer group