Salesforce handles the infrastructure, but you handle the configuration. When it comes to Experience Cloud that Shared Responsibility line is blurry, and at times even dangerous.
Back in 2021, Varonis published a blog post that should be required reading for anyone running a portal on the Salesforce platform. They identified how easy it is for bad actors to scrape your Salesforce database—Leads, Contacts, Accounts, Opportunities, and Custom Objects alike—not by “hacking” in the traditional sense, but by simply requesting for the data using standard APIs made available on your Salesforce Digital Experience site.
The Problem: APIs Don’t Care About What’s On the Page
One big misconception I see is the idea that if a piece of data isn’t displayed on a Visualforce or Lightning page, it’s safe from the public.
That is 100% false.
When you enable an Experience Cloud site, Salesforce creates multiple profiles–a Guest User profile to handle anonymous traffic and others to handle authenticated users of the site. If those profiles are granted “Read” access to an object—even if that object isn’t used anywhere on your site—the data is still accessible via Salesforce’s standard API endpoints. That means if your org’s external sharing model isn’t locking down access to the Lead object’s records, then a script can hit your Org, query the API, and walk away with your lead database.
How to Detect the Risk
You need to audit your Salesforce portals immediately if you think you’re at risk of data exposure. Don’t assume the defaults are protecting you.
- Object & Field Level Permissions: Go to your site-related profiles. If “Read” is checked on any object/field containing PII (Leads, Contacts, Accounts) that doesn’t need to be public, you might have a leak.
- External Sharing Settings: Go to Setup > Sharing Settings. If any object from step #1 is set to at least Public Read Only then you definitely have a leak.
- Sharing Gaps in Apex: Is your site leveraging any custom Apex logic? If so, all SOQL & DML statements should be leveraging USER_MODE and with sharing should be applied in the Apex class declaration, otherwise you could be over-exposing data.
How to Block It
In addition to running through the audit steps listed above you should secure your experience sites via:
- Secure Guest User Record Access: Go to Setup > Sharing Settings. Ensure “Secure guest user record access” is enabled. This is the “kill switch” that prevents guest users from seeing any records they don’t explicitly own (which, as anonymous guests, should be nothing).
- Guest User Sharing Rule Access Report: Go to Setup > Guest User Sharing Rule Access Report and select the site you’re auditing. Confirm that the guest user is not able to access more objects, records, fields, or personal data than they should.
- Third Party Audit: Sometimes a second set of eyes makes all the difference. Finding a trusted vendor that knows the ins and outs of Salesforce security can help lock down your org from sensitive data exposure.
The Bottom Line
Salesforce provides the tools to secure your perimeter, but they won’t click the buttons for you. If you haven’t audited your Experience Cloud sharing rules in the last six months, you aren’t just at risk—you’ve likely already had sensitive data scraped.
If you want to see exactly where your Shared Responsibility line is currently being crossed, we can help you run a full diagnostic.
Book a 15-Minute Security Strategy Call
Reference(s):
https://www.varonis.com/blog/misconfigured-salesforce-experiences