One thing that consistently comes up is the need to secure our business applications, and today, we’re going to demystify some concepts around securing a platform many companies rely on: Salesforce. Think of Salesforce as a super-powered digital Rolodex and operations hub for businesses, managing everything from sales leads to customer support. And just like any powerful system, if not handled with care, it can be a significant security risk.
Let’s break down some key security considerations for Salesforce, simplified for those of you just dipping your toes into the information security waters.
1. Data Leaks: The Unintended Share
Imagine you have a secret diary, and you’ve explicitly given permission for only your best friend to read certain pages. Now, imagine a hidden loophole in your diary’s lock that, if not explicitly sealed, allows anyone to read all the pages, regardless of your specific permissions for your best friend. This is similar to what can happen with Salesforce data.
In Salesforce, developers write “Apex code” to build custom features. “SOQL” is the language they use to ask the Salesforce database for information—like “show me all customer names” or “give me the sales figures for last quarter.” The critical part here is “with sharing.” This is a security keyword developers use that should make sure that when their code runs, it respects the user’s existing security permissions (like who can see what data).
However, if developers don’t also explicitly enforce what’s called “object- and field-level security,” then even with “with sharing,” their code might accidentally fetch and expose data that a user isn’t supposed to see. It’s like your diary lock only checking if someone is your “friend” but not checking if they’re allowed to read that specific page. This can lead to sensitive company data falling into the wrong hands internally or externally. Always assume malicious intent and apply the strictest necessary permissions.
2. Credentials: The Password Problem
it’s a universal cybersecurity truth: never, ever store passwords or other sensitive access information in a readable format (cleartext). It’s like writing your ATM PIN on the back of your debit card. If an attacker gains access to where these are stored, it’s game over. Always use secure methods like encryption or token-based authentication, which essentially use temporary, single-use keys instead of your actual password.
3. Managed Packages and Connected Apps: Trust, But Verify
Many companies extend Salesforce’s capabilities by installing “Managed Packages”—these are like pre-built apps from other software vendors. When these packages need to interact with your Salesforce data, they don’t ask you for your username and password directly. Instead, they use “OAuth 2.0” and “Connected Apps.”
Think of “Connected Apps” as a secure delegation system. When you authorize a managed package, you’re essentially telling Salesforce, “Okay, this app can access my data on my behalf, but only in specific ways.” It uses “namespaces” to keep its code separate from yours, preventing conflicts. This is a good thing as your actual credentials are never shared with the third-party app.
However, here’s the catch: a Connected App within a managed package might be granted “API Enabled” permission. This means it can programmatically access your Salesforce data even if your individual user profile doesn’t have that permission. This is powerful functionality, designed to allow the package to do its job. But if that managed package is malicious or has a vulnerability, it could be exploited to access data or perform actions on your behalf that you wouldn’t normally be able to do, effectively bypassing your direct security settings. It’s crucial to thoroughly vet any third-party apps you integrate.
4. The REST API: Your Data’s Digital Doorway
Salesforce also allows access to its data through “REST APIs.” Think of an API (Application Programming Interface) as a set of rules and tools that lets different software applications talk to each other. The REST API is like a digital doorway that allows other systems or custom scripts to read from or write to your Salesforce data.
The “API Enabled” permission is key here. If your user profile or permission sets have this, you can make these programmatic calls. As mentioned with managed packages, a Connected App might have this permission regardless of your individual user settings, allowing it to make API calls on your behalf. This highlights the importance of understanding the permissions granted to every app and user in your Salesforce environment. Every open door, even a seemingly small one, needs to be secured and monitored.
In essence, securing a platform like Salesforce is about understanding how data flows, who has access to what, and how third-party integrations work. It’s about layers of defense, constant vigilance, and always assuming that someone will try to find a weakness. Source: