Despite Salesforce’s widespread use and enterprise-grade architecture, it is not “secure by default.” In fact, its default configurations—especially around access control—can leave critical data exposed unless explicitly reviewed and hardened.
This assumption of built-in security is not only misleading but potentially dangerous. Salesforce security is a shared responsibility, and default settings are just the beginning, not the benchmark.
We’ll explore why this is so important and what your team can do about it.
1. Why Defaults Aren’t Enough
Most Salesforce orgs begin with broad permissions, generous sharing rules, and a patchwork of profiles and roles meant to accommodate speed over security. Default settings—like object-level access that includes read/write or org-wide defaults (OWDs) set to “Public Read/Write”—might help teams hit the ground running, but they create attack surfaces that widen over time.
Salesforce doesn’t restrict access unless explicitly configured to do so. That’s by design. It gives organizations flexibility to support their business processes. But flexibility without guardrails means many orgs remain vulnerable to inadvertent exposure or insider abuse.
In 2023, numerous Salesforce community websites were found to expose sensitive data because of misconfigurations. This is a perfect example of the importance of intentional settings within your Salesforce environments.
2. The Risk of Permissions Creep
Over time, Salesforce admins and developers incrementally grant new access to users, roles, or profiles just to unblock a workflow or resolve a support ticket. Without a mechanism for review and rollback, these incremental grants pile up—what’s known as permissions creep.
This phenomenon is especially risky in complex Salesforce environments where multiple teams have overlapping needs.
A user who once needed temporary access to a high-privilege profile might still retain it years later, with no business justification. That creates unnecessary lateral movement paths for attackers—or simply increases the chances of data leakage via negligence.
3. Profile and Permission Set Drift
Profiles and permission sets are often cloned and modified across sandboxes and production environments. But unlike application code, they don’t always follow version control or change management best practices. That makes it easy for inconsistencies to develop—and for unintended access to slip through the cracks.
Worse, updates to custom objects or managed packages often introduce new fields or permissions, and if your profiles aren’t regularly reviewed and updated, users might gain access to sensitive data by default simply because no one denied it.
4. Understanding the Shared Responsibility Model
Salesforce’s Trust & Compliance documentation makes it clear: Salesforce is responsible for the platform security, while customers are responsible for application and data security within that platform.
This means access controls, visibility rules, API restrictions, audit logging, and field-level security are all your responsibility. And unlike infrastructure platforms such as AWS or Azure, Salesforce doesn’t provide the same kind of “least privilege by default” stance. Unless you’ve proactively configured your org, your data might be accessible to far more users than you realize.
5. The Risks of Failing to Update Access Controls
The consequences of failing to regularly update access controls are not theoretical. Real-world breaches and compliance violations often trace back to overly permissive access.
Consider the implications:
- Regulatory exposure: If PII or financial data is accessible beyond what’s justified, it could violate GDPR, CCPA, HIPAA, or SOX—depending on your industry.
- Insider risk: Disgruntled employees or third-party users with lingering access can exfiltrate data or damage your CRM environment.
- Shadow IT and API misuse: Without strict permission and token policies, apps or integrations can siphon off sensitive data without oversight.
And because Salesforce data often feeds downstream systems such as marketing automation and customer service platforms, these risks don’t stay contained.
6. Steps Toward a Secure Salesforce Posture
Security in Salesforce must be proactive and iterative. Here’s how to begin strengthening your posture:
- Ensure clean code: Scan all code against security and quality standards to ensure updates and applications operate as intended without introducing new security vulnerabilities and technical debt.
- Run regular access audits: Review user access, profile assignments, and permission set usage quarterly at a minimum. Use automation where possible to detect anomalies.
- Harden default settings: Set org-wide defaults to private, enforce field-level security, and disable guest user access unless explicitly required.
- Implement change control for metadata: Treat profiles, permission sets, and sharing rules like code—versioned, tested, and reviewed before deployment.
- Leverage automated tools: Solutions like AutoRABIT Guard provide automated data classification and access risk detection, helping teams continuously identify misconfigurations and overexposed records.
- Train administrators and developers: Make sure your team understands the risks of default behavior and the need for security-first development.
7. Building a Culture of Continuous Vigilance
Ultimately, Salesforce security isn’t a checkbox—it’s a practice. It demands the same rigor and scrutiny that we apply to infrastructure security. The goal isn’t just to lock down the system, but to create a culture where secure configuration is the default mindset—even if the platform itself doesn’t enforce it by default.
Leaders should think of Salesforce not as a CRM, but as a data platform—and treat its configuration surface accordingly.
That means embedding security reviews into sprint cycles, giving ownership of data security to the right stakeholders, and ensuring that misconfigurations are treated as incidents, not oversights.
Control. Resilience. Security.
Salesforce can’t be considered “secure by default” because it was never designed to be. It’s a flexible, powerful platform built for scale—but that flexibility comes with responsibility. Standard configurations are rarely sufficient, and assumptions about built-in safety can lead to real-world breaches.
To stay secure, teams must recognize their role in the shared responsibility model and invest in continuous improvement—from auditing access to enforcing least privilege principles. Because in Salesforce, security isn’t what you inherit. It’s what you build.