Top 3 riskiest misconfigurations on the Salesforce platform
Gartner estimates that by 2025, 70% of enterprise applications will be built on low-code and no-code platforms such as Salesforce and ServiceNow. But are these platforms providing a false sense of security?
When asked, Salesforce administrators often reply that the company is responsible for security. Security is a shared responsibility on SaaS applications. Your provider secures the infrastructure, and your administrators and developers are responsible for ensuring least privilege access rights.
Cloud misconfigurations are responsible for a three-fold increase in data breaches. Typically, misconfiguration occurs when security settings are allowed to default, inappropriate access levels are assigned, or data barriers are not created to protect sensitive data. Configuring a low-code platform is so easy that the low-code administrator often does not understand the impact of checking a box.
When looking at the impact of a simple checkmark, these are the top three riskiest misconfigurations on the Salesforce platform: Modify All Data (MAD) and View All Data (VAD), Sharing & Sharing Groups and Running Apex code without the “runAs” method.
Let’s look at each and the impact they can have.
Sharing Groups are very powerful, but they can potentially open up accidental access to unauthorized users.
MAD and VAD
We’ll start with the obvious and most dangerous. Modify All Data and View All Data permissions do exactly what they say. These are the super user permissions for Salesforce.
If a user has VAD, they have read access to every data record in the system. MAD means they can update and delete every record as well. These permissions should only be given to administrators and even then, to a very limited number of people.
Why would an admin be tempted to give MAD or VAD to non-admins? The typical case is when a user is not able to access data that they have a need to see. The admin reviews the user’s profile and permission sets, all of the sharing rules and role hierarchy, and can’t determine why the user can’t see the information. As a “temporary fix,” they give the user MAD or VAD and now the user can see the records — along with everything else in the system.
This mistake can also happen when developers run into the same dilemma. They temporarily turn on MAD in the user profile in order to make progress in their code and later forget that they turned it on.
