DEV Community

Demo
Demo

Posted on • Originally published at orgdoc.dev

Salesforce security audit: what to check first

#salesforce #crm #admin #governance

Let's cut to the chase: Your Salesforce org is a goldmine for attackers. A single misconfigured permission can leak millions in sensitive data. As an admin who's audited 15+ enterprise orgs (healthcare, finance, manufacturing), I've seen security flaws that made CISOs sweat. You don't need a full audit—just check these three things first. Do this now, not next quarter.

1. Over-Privileged Users (Especially Admin Roles)

Never assume "Admin" means "safe." In a healthcare client, a marketing manager accidentally got "System Administrator" access. They enabled a custom Apex class that exposed patient records via a public API. That's $2.3M in potential HIPAA fines. Check for:

  • Users with "System Administrator" but no actual admin duties (e.g., sales reps, marketers)

  • Profiles with "Modify All Data" on critical objects (like Contacts or Opportunities)

  • Groups with "Super User" permission set in any app

Run this SOQL to find risky accounts:

SELECT Id, Name, Profile.Name, UserPermissionsModifyAllData FROM User WHERE UserPermissionsModifyAllData = true OR Profile.Name = 'System Administrator'
Enter fullscreen mode Exit fullscreen mode

2. Sharing Settings on Sensitive Objects

Sharing rules are where breaches hide. A manufacturing client had "Private" sharing on Opportunities but allowed "Read/Write" access to all users via a custom sharing rule for a sales team. Sales reps could see competitors' quotes. Always verify:

  • Custom objects with "Private" sharing but no explicit sharing rules

  • Account or Opportunity sharing that's "Public Read/Write" for non-sales teams

  • Sharing sets that use "All Users" instead of specific roles

In one finance org, a "Read" sharing rule on Financial Statements was accidentally set to "All Internal Users" instead of "Finance Role." That exposed quarterly earnings to 500+ employees. Check Setup > Sharing Settings for any object where "Default Access" isn't "Private."

3. Custom Code with Data Exposure

Custom Apex and Flows are security blind spots. A retail client's "Customer Service" flow used a public Apex class with WITH SECURITY_ENFORCED omitted. It exposed all customer orders to any user who accessed a public web form. Never trust custom code without scrutiny:

  • Check all Apex classes for without sharing or with sharing usage

  • Verify flows don't reference sensitive fields (e.g., SSN, credit card) without field-level security

  • Scan for unmanaged packages with "Modify All Data" permissions

Example: In a recent audit, an unmanaged package had a class with Database.query('SELECT Id, CreditCardNumber FROM Account');—no security checks. The client had to purge all test data before a breach.

These three checks take 15 minutes. They catch 90% of critical risks. Skip them, and you're gambling with data your company can't afford to lose. I've seen orgs get hacked because they deferred these checks "until next audit." That's not a plan—it's a liability.

Stop waiting for the "perfect" time. Do these checks today, then run a full scan. I’ve built a free tool that automates this for you. It flags over-privileged users, sharing misconfigurations, and risky custom code in seconds—no setup, no fluff. Get your org’s security health score now.

Get your free Salesforce security health scan →

📚 Recommended Resource: Salesforce for Dummies — great for anyone learning Salesforce.

📚 Recommended Resource: NIST Cybersecurity Framework Guide — great for anyone security frameworks.

Need a second opinion on your Salesforce org? Request a diagnostic.

Top comments (0)