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.

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.

Join 10k+ tech and VC leaders for growth and connections at Disrupt 2025

Netflix, Box, a16z, ElevenLabs, Wayve, Sequoia Capital, Elad Gil — just some of the 250+ heavy hitters leading 200+ sessions designed to deliver the insights that fuel startup growth and sharpen your edge. Don’t miss the 20th anniversary of TechCrunch, and a chance to learn from the top voices in tech. Grab your ticket before Sept 26 to save up to $668.

Join 10k+ tech and VC leaders for growth and connections at Disrupt 2025

Netflix, Box, a16z, ElevenLabs, Wayve, Sequoia Capital, Elad Gil — just some of the 250+ heavy hitters leading 200+ sessions designed to deliver the insights that fuel startup growth and sharpen your edge. Don’t miss the 20th anniversary of TechCrunch, and a chance to learn from the top voices in tech. Grab your ticket before Sept 26 to save up to $668.

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.

To fix this, organizations should employ a tool that scans production and new deployments for MAD/VAD permissions and flags any changes. At a minimum, admins should be trained to never enable these permissions for anyone who is not an admin. A better practice is to make changes in sandboxes and promote them with a DevOps tool, limiting the number of admins in production to one or two individuals.

Sharing and sharing groups

Sharing rules and the role hierarchy are very powerful tools to control which records a user can access, but they also have side effects that are often not obvious. Create, read, update and delete (CRUD) object permissions and even Field Level Security (FLS) are much easier to understand. They are all or nothing, but record sharing is designed to restrict a subset of records at a time.

Let’s take the ability to make an object public. When an object is public, everyone in the organization can see every record of that type. This is sometimes acceptable but only if it is a good idea for every user to see every record for that object. It is usually best practice to make objects private and get clarity on which users should have access to which records. Things get more complicated when these objects are shared with portal users through the Experience Cloud.

Here’s an example of unintended consequences at a temporary employment agency. The agency used a Salesforce customer portal to capture time cards from their temps. The time card page was a custom angular page. A large group of internal employees needed access to these time cards, so the admin decided to make the object public with full read/write access for all users. What they didn’t understand was the option led to sharing with portal users. By sharing with portal users, they made these records read/write for them as well.

Salesforce uses Uniform Resource Identifiers (URIs) to represent each page, and the URI for the angular application contains the unique ID of the standard Salesforce record. When one enterprising temp started erasing the end of the URI, they arrived at a standard Salesforce page with a large edit button. The standard page included all of the fields of the object, including the temp’s hourly salary. With a few clicks, this temp gave himself a nice raise.

The first lesson to be learned here is that sharing controls for portal users should be scrutinized to ensure least privilege access for those users. The second lesson is that SaaS applications can be manipulated by changing the URI in the browser address bar, and this applies to all REST API applications.

Sharing Groups are very powerful, but they can potentially open up accidental access to unauthorized users. The challenge lies with the reality of managing a large enterprise.

As admins start defining sharing groups, it is easy to remember who the members are based on the group names. As more groups are added, however, the more difficult it becomes to distinguish the group members from the names. In fact, when the number of groups increases, it’s likely that groups with small differences in membership will be consolidated.

Eventually, you will create a sharing rule for a group that sounds like it contains the right members, but it may also include several other members that were added by other admins during a consolidation. Now all of these other members get access to the same potentially sensitive information.

To avoid this, you should educate admins on the nuances of these rules and incorporate functional testing of data access in your test suites to ensure sensitive data is not exposed.

The “runAs” method

From the Apex Developer’s Guide:

Generally, all Apex code runs in system mode, where the permissions and record sharing of the current user aren’t taken into account. The runAs method doesn’t enforce user permissions or field-level permissions, only record sharing.

There are two potential problems with runAs. The first is not using it! Even if the admin team does a perfect job of setting up the sharing hierarchy and rules, poorly written Apex code will bypass record sharing unless it is enforced using the runAs method. Developers should be aware of this issue and write their code to enforce sharing appropriately. With runAs, the running user will ensure that this user’s access rights are applied and prevent sensitive information from being exposed.

The second potential problem is the fact that field level permissions are not enforced even in runAs blocks. This opens up the potential for exposing sensitive information stored in a record that the user can access but is protected by field-level security. The temp worker salary story above is a good example. Security may be set up to hide this field from one set of users, provide read-only access to another set of users and read/write access to a very limited number of users. However, a developer can write a lightning controller that bypasses these controls without intending to do it.

In this case, it is important to educate developers on the nuances of these rules, incorporate functional testing of data access in test suites to ensure sensitive data is not exposed and run tests under all of the user types who will have access to the Apex.

Test every path

While greater education and awareness is important to reduce inadvertent access, it will never be a complete solution. Rigorous testing is a must for identifying the mistakes that people make. This involves test automation that accounts for more than just the happy path. Your test organization should always understand the intended access rights associated with sensitive information and design tests that run in the context of all of the users who need access — and even those that don’t.

Running under every possible profile and role is generally impractical, but judiciously choosing a representative variety of users will identify most mistakes. There may be 50 or more different profiles in a given production environment, but they will usually segment into a small number of groups: Those with no access, those with read access and those with read/write access to the sensitive information. Identify those groups and run tests as a user from each and verify both positive and negative access.

Functional testing tools are able to access data just like a user through the browser, so all of the issues can be caught, including lightning components that fail to use runAs.

Finally, security is a shared responsibility for SaaS applications. Point-and-click security settings are very powerful but with great power comes great responsibility.

Editor’s note: a previous edition of this article was incorrectly attributed to the wrong contributor; we regret the error.