Varonis researchers have recently disclosed that several government agencies and private-sector companies had customized or added features to their Salesforce Apex code that leaked data, allowed data corruption, or allowed an attacker to disrupt business functions.
Impacted data included the usual suspects like phone numbers, addresses, social security numbers, and username/password combinations.
Because of the obfuscated nature of custom Apex code that is used in internal Salesforce instances and apps (i.e. Lightning, Lightning Communities) is at the root of the problem. As people are building their own apps and automations, there are also a variety of settings, steps, and configurations that need to happen that are often missed due to the lack of a software development lifecycle that takes place across Salesforce, and other low-code platforms like it.
Unfortunately, there are a couple of issues that make it very easy for Salesforce devs (consisting of both professional and citizen developers) to make mistakes that can lead to data leakage. The key issue in this case, however, can be distilled down to whether a developer designates an Apex class as ‘with sharing’ or ‘without sharing.’
What’s interesting with how Salesforce has set up their platform, is the ‘without sharing’ designation is actually the security nightmare, as it allows Apex code to ignore users’ permissions and change and commit changes to any record. As this happens, bad actors can gain access to more things than they need, and are essentially granted super-admin powers to be able to change any record with very little in the way of governance.
As with most things, it is not so simple as to just tell users to not select ‘without sharing’ when designating Apex classes. For one, this classification is a ‘powerful and important capability often required for proper functionality,’ and is always going to be needed; the real questions are, ‘when is this needed’ and ‘how do I prevent unnecessary designations to occur?’
The Varonis recommendations are to avoid this ‘without sharing’ configuration when possible, to check user-supplied inputs, and be extra vigilant when allowing guest users to access and use Apex classes. The underlying recommendation is to better educate business users that are developing their own resources inside of Salesforce.
The problems are threefold:
While many tools are available to assist with ‘security for Salesforce’ the way these tools work are often to persist on an access control level; that is to limit the very use of Salesforce (or other SaaS development platforms) to only the people that need it to do their jobs; often associated with SSPMs. There are other data-security tools (i.e. DSPMs) that aim to classify data that exists within the SaaS platform and approach security that way.
However, the problem still exists that there are huge numbers of people that need access to these SaaS tools, and the data that need to be integrated and connected to the offshoots coming from these SaaS tools; namely apps, automations, dataflows, and even copilots. Further, because these tools all exist at the surface level and are not able to properly distinguish between apps where it makes sense to have this ‘without sharing’ label make sense, and where it does not.
What can be done to prevent and mitigate the risk from this specific incident (and likely many more to come as more and more people adopt AI and low-code development platforms) is as follows:
If you’d like to see this in action, Zenity offers full security and governance support for Salesforce, including the ability to flag any Apex code that has been designated as ‘without sharing,’ and providing automated remediation steps. Check out our solution page, or get in touch with us at hello@zenity.io to learn more!
All ArticlesIntroduction Enterprises are racing to adopt AI copilots and low-code/no-code platforms to innovate and maximize...
Microsoft Fabric is an end-to-end analytics and data platform that covers a wide range of functionality, including...
In a rapidly evolving digital landscape, data security has become a paramount concern within the AppSec community....
We’d love to chat with you about how your team can secure and govern AI Agents everywhere.
Book Demo