Salesforce Access Risk: How Hidden Permissions Create Security Blind Spots

Ask a Salesforce Admin who has the most privilege in their Salesforce organization, and they will likely point to users with the System Administrator profile. That’s a reasonable answer, but it’s incomplete. Privilege is distributed across hundreds of individual settings: profiles, permission sets, API tokens, connected apps, and automation configurations. The result is a group of security principals with unknown capabilities: users, integrations, and automations that have accumulated enough privileges to be potentially dangerous. But, no one is looking for them.

Before we can uncover these unknown capabilities, we need to answer a more fundamental question: What does privilege actually mean in Salesforce?

In most security contexts, “privileged” usually means administrative access, the ability to make organizational changes, or access to sensitive data that most users cannot reach. In many systems, the platform itself defines what counts as privileged. Salesforce, however, does not. That ambiguity is part of the problem. If we really want to understand who has privilege in a Salesforce organization, we first need a clear, shared definition of what “privilege” actually means.

For our purposes, a privilege stems from any Salesforce setting, permission, or capability that grants a security principal the ability to:

• Access, modify, or export data at scale

• Modify or override security controls, access policies, or audit configurations

• Grant, escalate, or modify privileges and permissions for themselves or others

This distinction matters because Salesforce has hundreds of configurable permissions, and not all of them are equally dangerous. Modify All Data is obviously very powerful, as it lets a user read and write every record in the organization. But the Manage Auth. Providers privilege is arguably just as dangerous, as it lets someone reconfigure how the organization can authenticate its users. The difference is that one is widely recognized as high-risk, while the other often flies under the radar.

One of the reasons Salesforce privileges are so difficult to pin down is that they aren’t defined in one particular place. There’s no single permission table you can query to get the full picture. Instead, privileges are scattered across several mechanisms, and a security principal’s effective access is the combination of all of them.

Profiles and Permission Sets

In Salesforce, every user’s access is built on two foundational building blocks: profiles and permission sets. A profile is required for each user and assigned when a user is first created. It defines the baseline of what they can do. Permission sets, on the other hand, are optional additions that layer on top of a profile, granting extra capabilities without modifying the profile itself.

Because the model is purely additive, you can give someone more access, but you cannot take any away through a permission set. A user with a restrictive profile and 10 permission sets may end up with far more access than intended.

Some of these permissions are not as straightforward as they appear. Enabling one can quietly unlock several capabilities underneath. Modify All Data, for instance, doesn’t just let you edit records; it implicitly grants read, create, and delete access across every object in the organization.

Unmanaged privilege is a growing concern for most organizations. A sales analyst is assigned a permission set to resolve a reporting issue, and it is never removed. A marketing integration ends up with over-privileged access that is not audited. A developer maintains the Author Apex permission after moving to a non-technical role. These scenarios are realistic to many organizations today. Permissions accumulate over time and create unintended privilege that attacks can abuse.

Security review tends to focus on profiles without considering the combined effect of every permission set, every connected app, and every piece of automation that a security principal touches. The effective privilege of a security principal is the sum of all these parts, and that sum is almost always larger than expected.

To help security teams start understanding privilege in Salesforce, we‘ve cataloged Salesforce’s privileged primitives that can be assigned to security principals. The spreadsheet that can be found here is an inventory of the primitives that can be found in Salesforce, along with whether it is privileged.

The effective privilege of a given user or third-party integration in Salesforce tends to grow unexpectedly, due to the sprawling, additive model that spans profiles, permission sets, connected apps, and more. As we’ve seen, a user with nothing more than a Read-Only profile and a single permission can bypass record-level security. The result is an environment where effective privilege is almost larger than intended, and the security principals carrying that privilege are rarely the ones anyone is watching. Finding and mapping these shadow administrators is not a one-time audit; it’s an ongoing practice that requires understanding of how all these pieces fit together.