Technology Top 3 Riskiest Misconfigurations on the Salesforce Platform • businessroundups.org Ana LopezNovember 23, 20220367 views Andrew Davis is senior director of methodology at Copado. He is a Salesforce DevOps specialist focused on the next generation of DevOps 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 do these platforms give a false sense of security? When asked, Salesforce admins often answer that the company is responsible for security. Security is a shared responsibility with SaaS applications. Your provider secures the infrastructure and your administrators and developers are responsible for ensuring least privileged access. Cloud misconfigurations are responsible for a tripling of data breaches. Misconfiguration usually 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 doesn’t understand the impact of ticking a box. Looking at the impact of a simple check, these are the three most risky 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 take a look at each and the impact they can have. Sharing Groups are very powerful, but they may accidentally give access to unauthorized users. MAD and VAD We’ll start with the obvious and most dangerous. Change 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, he has read access to every data record in the system. MAD means they can also update and delete any record. These permissions should only be given to administrators and even then to a very limited number of people. Why would an administrator be tempted to give MAD or VAD to non-administrators? The typical case is when a user cannot access data that they need to see. The administrator reviews the user’s profile and permission sets, all sharing rules, and the role hierarchy, and can’t determine why the user can’t see the information. As a “workaround” they give the user MAD or VAD and now the user can see the records – along with everything else in the system. This error can also occur when developers run into the same dilemma. They temporarily turn on MAD in the user profile to make progress in their code and later forget they turned it on.