The 33 Salesforce Dangerous Permissions (And How to Find Who Holds Them)

The 33 salesforce dangerous permissions that create real attack paths in your org, organized by category, with SOQL queries to find who holds them today.

Salesforce dangerous permissions are one of the most common security problems in orgs, and one of the least visible. A user gets a permission set for a project. The project ends. The permission stays. A year later, that same user has accumulated access that no single admin intentionally granted, but nobody removed either.

The result is users with combinations of permissions that create real attack paths through your org.

This post covers the 33 permissions that matter most from a security standpoint, organized by the type of risk they introduce. It covers which combinations are genuinely dangerous (not just theoretical), includes SOQL queries you can run today to find who holds them, and explains what continuous permission monitoring actually looks like in practice.

What Makes a Salesforce Permission "Dangerous"

Not every permission is a security risk. Creating a custom report type is not dangerous. Bypassing sharing rules, exporting your entire org's data, or impersonating other users is.

A permission qualifies as dangerous when it meets at least one of these criteria:

  • It enables access to data the user's role and profile should not allow
  • It lets the user act as someone else or override normal auth controls
  • It enables bulk export or exfiltration of data at scale
  • It allows code execution or configuration changes that persist after the session ends
  • It can be stacked with other permissions to create a path that no single permission would open alone

The 33 permissions below meet those criteria. They fall into five categories: Data Access, Admin Override, Auth Bypass, API and Integration, and Code Execution.

Category 1: Data Access Permissions (9 permissions)

These permissions control what data a user can read or modify, regardless of what sharing rules, record ownership, or org-wide defaults say.

View All Data gives read access to every record in the org. Sharing rules, private OWD settings, territories: none of it applies. A user with View All Data can see every Account, Opportunity, Contact, and custom object record you have.

Modify All Data goes further. Read and write access to every record, including the ability to delete. A user with this permission can mass-delete records, edit closed Opportunities, or overwrite data in regulated fields with nothing stopping them.

Export Reports lets a user export report results to CSV or Excel. Paired with View All Data, this is the most common data exfiltration setup in Salesforce orgs: see everything, download everything.

Manage Data Integrations covers Data Loader and similar bulk data tools with elevated privileges. It bypasses normal API-level sharing enforcement for data operations.

View Encrypted Data exposes fields encrypted via Salesforce Shield or Classic Encryption. Without this permission, encrypted fields show masked values. With it, the user sees cleartext.

Bulk API Hard Delete lets users permanently delete records via the Bulk API, bypassing the Recycle Bin. Irreversible at the API level.

Report on All Users lets a user include any Salesforce user in reports, including users they would not normally have access to through role hierarchy or sharing.

Manage Content Permissions covers access rules for Salesforce Files and Content records. A user with this permission can modify who can see shared documents.

View All Forecasts bypasses forecast sharing rules and exposes every user's forecast data across every territory.

Tip: View All Data and Modify All Data are frequently assigned to integration users or sandbox admins and never removed. Run the SOQL audit below to find every user holding these permissions across profiles and permission sets.

Category 2: Admin Override Permissions (8 permissions)

These let users bypass normal Salesforce governance controls, override configuration, or operate with admin-level authority without the System Administrator profile.

Modify All (object-level) is the object-specific version of Modify All Data. Full read, create, edit, delete, and view all access on one specific object. Often assigned to give a user "full access" to an object without thinking through what that actually includes.

Manage Users covers creating, editing, and deactivating users, assigning profiles, assigning permission sets, and resetting passwords. A user with Manage Users can elevate their own access or someone else's. It is effectively admin-level control over identity management.

Manage Profiles and Permission Sets lets a user create and edit profiles and permission sets, including adding dangerous permissions to existing ones. Paired with Manage Users, this is complete admin access without the System Administrator profile.

Delegated Administration is a scoped version of Manage Users, but the scope is frequently set too broadly. Delegated admins can manage users in specified roles and assign specified permission sets. If sensitive permission sets are in scope, a delegated admin can escalate their own access.

Manage Sharing covers org-wide defaults, manual shares, and sharing settings. A user with this permission can flip the OWD for a sensitive object from Private to Public Read/Write and expose every record.

Customize Application covers creating and modifying custom objects, fields, validation rules, flows, and page layouts. Granted broadly for "power users" without recognizing that flow creation comes with it.

Manage Flow covers creating, editing, activating, and deactivating flows. An active flow runs with the permissions of the user who activated it (or in system context for auto-launched flows). Misconfigured or malicious flows are a common privilege escalation vector.

Override Forecasts lets a user change another user's submitted forecast numbers. Lower on the danger scale, but creates audit integrity problems in revenue reporting.

Category 3: Auth Bypass Permissions (5 permissions)

These affect how a user authenticates, or how authentication requirements apply to them.

Log In As lets an admin authenticate as any other user without knowing their password. Every action during a Login As session is logged under the impersonated user's name by default, not the admin's. That makes it a potential audit trail evasion mechanism.

Waive Multi-Factor Authentication (MFA Bypass) exempts a user from the org-level MFA requirement. No second factor needed to log in, regardless of what the org's session security settings say.

Manage Two-Factor Authentication in User Interface lets a user manage (add, remove, or reset) MFA methods for other users. Paired with Manage Users, this opens a path to disable MFA for specific target accounts.

Bypass Identity Confirmation exempts a user from browser fingerprint and device trust checks. When Salesforce detects an unrecognized device, it normally sends an email confirmation. This permission skips that step.

Login IP Ranges Override (embedded in some permission sets via trusted networks) lets users log in from outside the org's allowed IP ranges. If your org uses IP restrictions as a defense layer, this blows through it.

Category 4: API and Integration Permissions (6 permissions)

These control what a user or connected application can do via the Salesforce APIs, which run outside the normal UI guardrails.

API Enabled is the base permission for any API access. Without it, a user cannot connect via REST, SOAP, or Bulk API. Most orgs grant this broadly without realizing it is the prerequisite for every API-based attack path in this post.

Apex REST Services lets a user invoke Apex REST endpoints. If any endpoint in your org runs in system context (without sharing), a user with this permission can trigger operations beyond their normal data access.

Manage Connected Apps covers installing, configuring, and modifying Connected Apps and External Client Apps. A user with this permission can add OAuth applications that authorize access to your org's data, including apps they control outside Salesforce.

Manage Auth. Providers covers Identity Providers and SSO settings. Misconfigured auth providers can redirect authentication to attacker-controlled endpoints.

Use Identity Features covers the Salesforce Identity feature set including app launcher, custom domains, and Identity Verification settings. Lower risk in isolation, but it amplifies other permissions.

Access Activities is not dangerous on its own. But paired with View All Data, it exposes every Task and Event across the org, including communication history and relationship data that sharing rules would otherwise restrict.

Category 5: Code Execution Permissions (5 permissions)

These let users write or execute code that runs inside your Salesforce org.

Author Apex lets a user write and save Apex classes and triggers. Apex runs on Salesforce servers with access to the database, API, and external callouts. A user who can author Apex can write code that exfiltrates data via HTTP callouts, modifies records at scale, or creates persistent backdoors.

Manage Apex covers compiling, managing, and deleting Apex classes and triggers. A user with Manage Apex can modify code that someone else wrote.

Create and Customize Dashboards is not a direct code execution risk, but dashboards built with Lightning Web Components can reference custom JavaScript. In practice this is low risk, but it creates an inconsistency in what "dashboard access" actually means for your security posture.

Lightning Console User (Service Cloud-specific) covers access to the Lightning Service Console, which can include Lightning Web Components running custom JavaScript. Risk depends on what components are installed.

Use Salesforce Functions covers Salesforce Functions (mostly deprecated now, but present in older orgs). Functions run Node.js or Java code inside Salesforce's compute environment with org access. Any user who can invoke them can run arbitrary code against your org.

Combination Risks: The Four Attack Paths

Individual dangerous permissions are a problem. What changes the category of risk is when these permissions stack. Here are four specific combinations that open complete attack paths.

Attack Path 1: Data Exfiltration

The permissions:

  • ViewAllData (see every record)
  • ExportReport (download report results)
  • APIEnabled (access via API)

A user with all three can build a report that includes every record in the org, export to CSV, and replicate the same operation via the API without touching the UI. No sharing rule, territory, or profile restriction stops this. A single compromised credential belonging to a user with this combination is a full data breach.

This is more common than most admins expect. Integration users and "power users" frequently hold all three because each was granted separately, for separate reasons, at different times.

Attack Path 2: Impersonation Plus Data Access

The permissions:

  • LoginAs (authenticate as another user)
  • ViewAllData (unrestricted data access)
  • ManageUsers (create/modify users)

This combination lets an attacker or rogue admin log in as any user, access any data, and then modify user records to reduce traceability. Actions taken in a Login As session appear in the audit trail under the impersonated user's name. The impersonator can then make changes to their own record or audit settings to cover the trail.

Often seen in orgs where a single admin accumulated these permissions incrementally rather than via the SA profile, or where a contractor had elevated temporary access that was never revoked.

Attack Path 3: Admin Takeover Without the SA Profile

The permissions:

  • ManageUsers (create/modify users)
  • ManageProfilesAndPermissionSets (edit permission sets)
  • WaiveMFA (bypass multi-factor auth)

A user with ManageUsers and ManageProfilesAndPermissionSets can grant themselves System Administrator-level permissions without touching the System Administrator profile. They can also create a new user, give that user elevated permissions, and log in as them (if they also have LoginAs). The WaiveMFA permission removes the second-factor checkpoint that would otherwise flag the session.

This combination usually appears in orgs where ManageUsers was granted for a legitimate purpose (creating a "user management role") without reviewing what else that user already held.

Attack Path 4: Code Injection via Flow

The permissions:

  • ManageFlow (create and activate flows)
  • CustomizeApplication (create custom objects and fields)
  • ModifyAllData (write to any record)

Flows can auto-launch on record events. A user with ManageFlow can create a flow that fires on every Account update, sends data via an External Service callout, and modifies records org-wide. ModifyAllData removes any record-level restriction on what the flow can touch. CustomizeApplication lets the user create the objects and fields that trigger the flow.

As a deliberate attack, this is less common. As an accidental vulnerability, it is very common. Power users granted ManageFlow for legitimate automation work frequently already hold the other two permissions without anyone having audited the combination.

How to Audit Permissions Manually with SOQL

Run these queries against your org to get a current baseline before setting up ongoing monitoring.

Find Users with View All Data or Modify All Data via Profile

SELECT Profile.Name, COUNT(Id) userCount
FROM User
WHERE Profile.PermissionsViewAllData = true
  OR Profile.PermissionsModifyAllData = true
  AND IsActive = true
GROUP BY Profile.Name

Find Permission Sets That Include View All Data

SELECT Name, PermissionsViewAllData, PermissionsModifyAllData
FROM PermissionSet
WHERE PermissionsViewAllData = true
  OR PermissionsModifyAllData = true
  AND IsCustom = true

Find All Active Users Assigned Dangerous Permission Sets

SELECT Assignee.Name, Assignee.Username, PermissionSet.Name
FROM PermissionSetAssignment
WHERE PermissionSet.PermissionsViewAllData = true
  OR PermissionSet.PermissionsModifyAllData = true
  OR PermissionSet.PermissionsManageUsers = true
  AND Assignee.IsActive = true
ORDER BY Assignee.Name

Find Users Who Can Bypass MFA

SELECT Name, Username, Profile.Name
FROM User
WHERE Profile.PermissionsCanInsertFreezeIceKeys = true
  AND IsActive = true

Tip: These queries give you a point-in-time snapshot. The problem with manual SOQL audits is that they go stale the moment you run them. A permission set can be assigned in the next hour and your baseline is already wrong.

Find Users Who Can Log In As Other Users

SELECT Name, Username, Profile.Name
FROM User
WHERE Profile.PermissionsLoginAsAnyUser = true
  AND IsActive = true

Note: The LoginAsAnyUser field name can vary by API version. In your Developer Console, run SELECT Id, Name, PermissionsLoginAsAnyUser FROM PermissionSet to confirm the field name for your org's API version.

Run these in your Developer Console (Setup > Developer Console > Query Editor) or via the Salesforce CLI with sf data query. For more on what Salesforce logs automatically, see What the Salesforce Setup Audit Trail Actually Logs.

Continuous Permission Monitoring with AuditForce

SOQL audits tell you who has what right now. They do not tell you when it changed or who changed it.

Permission assignments visible in your results today could have been set yesterday by a rogue insider, or two years ago during a project that closed long ago. Without timestamps, you cannot triage risk. Without change history, you cannot investigate incidents.

AuditForce's Permission Analyzer runs on your existing Salesforce connection and gives you two views:

Permission-first: Select any of the 33 dangerous permissions and see every user who holds it, through which profile or permission set, and when that assignment last changed. "Who has Modify All Data?" takes seconds instead of a SOQL query.

User-first: Search any user and see every dangerous permission they hold across their profile and all assigned permission sets on one screen. No manual cross-referencing of profile and permission set data.

Paired with the Change Detection daily digest, permission changes that appear in the SetupAuditTrail generate severity-categorized alerts. See The 5 Most Dangerous Salesforce Security Changes for the full list of what triggers a Critical or High alert. A new permission set assignment that includes View All Data shows up as a High severity change in your digest the same day it happens, not at your next quarterly review.

Building a Permission Review Process That Holds Up Over Time

Continuous monitoring catches changes as they happen. That still leaves the permissions set before you started monitoring, or ones that came in through profile changes rather than direct assignment.

A quarterly review that actually works focuses on three things:

The first is orphaned permission sets from finished projects. Create a naming convention for temporary sets (prefix with TMP_ or include a project code). Every permission set with that prefix gets audited quarterly and assignments get removed from users whose projects are complete.

The second is profile-level permissions before permission set assignments. Dangerous permissions in a profile affect every user on that profile. The blast radius is larger, so start there.

The third is integration users. These non-human accounts frequently hold View All Data, Modify All Data, and API Enabled because it was the easiest way to get an integration working. Integration users should hold only what their integration actually needs, and they belong in your quarterly review the same as human users.

SOQL baselines, quarterly hygiene, and daily change detection cover three different time horizons. Together they close most of the gaps that permission creep opens.

The 33 Dangerous Permissions by Category

Data Access (9): View All Data, Modify All Data, Export Reports, Manage Data Integrations, View Encrypted Data, Bulk API Hard Delete, Report on All Users, Manage Content Permissions, View All Forecasts

Admin Override (8): Modify All (object-level), Manage Users, Manage Profiles and Permission Sets, Delegated Administration, Manage Sharing, Customize Application, Manage Flow, Override Forecasts

Auth Bypass (5): Log In As, Waive Multi-Factor Authentication, Manage Two-Factor Authentication in UI, Bypass Identity Confirmation, Login IP Ranges Override

API and Integration (6): API Enabled, Apex REST Services, Manage Connected Apps, Manage Auth. Providers, Use Identity Features, Access Activities (with View All Data)

Code Execution (5): Author Apex, Manage Apex, Create and Customize Dashboards (with LWC), Lightning Console User, Use Salesforce Functions

The four combinations to prioritize: Data Exfiltration (ViewAllData + ExportReport + APIEnabled), Impersonation Plus Data (LoginAs + ViewAllData + ManageUsers), Admin Takeover (ManageUsers + ManageProfilesAndPermissionSets + WaiveMFA), and Code Injection via Flow (ManageFlow + CustomizeApplication + ModifyAllData).

Run the SOQL queries above to establish your baseline. Then set up the review cadence to keep it from drifting.