How to plug leaky Salesforce Experience Cloud sites
A new report has found that many organizations, including those with sensitive information like banks and healthcare organizations, are using misconfigured Experience Cloud (formerly known as Salesforce Community) websites that expose data to unauthenticated users.
Experience Cloud is a software product that makes it easy for companies to create websites. The websites provide content to both registered (or authenticated) users that are given login credentials, and guests without login credentials (unauthenticated users).
Last week, cyber security journalist Brian Krebs published an expose on several websites that were misconfigured by administrators to provide guests with access to sensitive data normally reserved for authenticated users. The type of information depends on the organization, but in one example highlighted by Krebs, guests could access data like social security numbers, phone numbers, and bank account numbers.
The problem isn’t a vulnerability or a flaw in Salesforce’s security: the issue stems from an apparent common misunderstanding on how to configure access rights for the website.
Specifically, the root cause behind all external users (including guests) being able to access this sensitive data is if object types are set with "Default External Access" as "Public Read" or "Public Read/Write” (more information on what Salesforce considers “external users” is available here).
This misconfiguration can allow an attacker to use the REST API available through the “Lighting Experience for Guest Users” feature to query the data, which is actually an issue that has been known and abused since 2021.
Fortunately, there are some straightforward mitigations for this issue:
- Disable the default external sharing, and then define sharing rules that allow access to the data only to the right user profiles/groups.
- Go to Salesforce Setup, search, and select Sharing Settings.
- Make sure your Default External Access settings are limited to private as much as possible.
- You should test setting all Default External Access settings to Private in your sandboxing environment.
- You can open object settings one by one per your specific needs.
- Important: if you want to follow the best security practices, keep all External Access settings private, and use sharing rules to extend sharing access to users that should possess access to said data. For example, their own records only, or based on groups, roles, or territories.
- Consider if disabling the "Lightning Experience for Guest Users" feature is an option for your organization. This prevents the Lightning REST APIs (which are used to query access to the data) from being available unless you are a non-guest user, and may make the issue harder to exploit.
According to WithSecure Principal Security Consultant Antti Tuomi, the apparent prevalence of this problem points to a broader security challenge facing organizations.
“Many organizations likely struggle to find the time and skills for maintaining and developing the platform’s security, meaning they may not read and evaluate the release updates. If you don't pay attention to changes and spend the time to analyze the security implications, a combination of small separate factors may add up to cause significant risks,” he explains. “Platforms like these are large and constantly evolving, and it’s important for organizations to ensure they allocate the necessary resources to ensure they can keep their implementations secure.”
Organizations that need additional support in reviewing security configurations and hardening their Experience Cloud or other platforms can contact our Cloud Security consultants here.
WithSecure also offers support in securing content shared via Salesforce, including free content risk assessments to help identify blind spots when it comes to data flowing in and out of Salesforce environments.