7 Actions Salesforce Teams Should Take to Secure Experience Cloud

Most Salesforce data breaches are not someone finding a hidden hole in the platform. They trace back to architecture decisions nobody reviewed, and Experience Cloud puts those decisions on the open internet for an attacker to find first.

Matt Meyers, CTA, Founder and CEO of EzProtect, hosted Lillie Beiting, author of Mastering Salesforce Experience Cloud and an enterprise Salesforce architect, to break down how guest user access, the data model, and custom code create exposure on public sites. As Lillie put it, this is not someone finding a vulnerability nobody ever thought about. It is exploiting sloppy design and sloppy security practices.

One framing matters before the tips. Experience Cloud sites come in three common shapes, and each carries a different threat model. Public help centers lean on the guest user. Partner portals are authenticated but risk one partner seeing another’s data. Customer communities add self-registration and record access. Lillie’s warning is that orgs running all three often design for only one, so read the tips below against the site type you actually run.

As many in the industry know from the first round of breaches in September, 2025, these attacks have been ongoing. As recently as March 2026, Salesforce confirmed a campaign in which the ShinyHunters group scanned public-facing Experience Cloud sites and extracted data from orgs whose guest profiles had overly broad permissions, stressing the issue was customer configuration and not a platform flaw. As Lillie noted in the session, some estimates put this over 1,300 organizations that have been hit by the broader ShinyHunters guest user campaign.

1. Misconceptions about Salesforce breaches 

Many  of these attacks traced back to a configuration decision by the people doing the config in the first place. The attackers were looking for doors left open and Salesforce said the same in its advisory, confirming the activity relates to configuration, not a platform security flaw. The exposure exists because your architecture created it, which means you can close it.

2. Unchecking “API Enabled” does not lock the door

Start here because it is the belief that bites people most often. Many admins assume that disabling API Enabled on the guest profile stops data access. It does not. If you have shared data through the Lightning APIs, an attacker can still query, insert, update, and delete records, and even execute flows and Apex. As Matt put it, if the guest user can reach it on the API layer, so can an attacker. The permission is still worth turning off. Salesforce calls disabling guest access to public APIs the highest-impact single change, because it closes the Aura endpoint that was the exact vector in the 2026 campaign. Just do not stop there.

3. Your guest user is your largest audience and your largest risk

Guest org-wide defaults are private, access flows only through sharing rules, and guests cannot own records or join queues. But object and field permissions on the guest profile, the scope of every guest sharing rule, and every Aura-enabled method a guest can reach are all yours. As Lillie put it, the floor is strong, but all the furniture in the room is your shared responsibility. Salesforce documents this division of work in its guest profile best-practices guidance, and now urges customers to enforce a least-privilege model. One detail to catch early: your template choice sets these defaults from day one, so a help center and a build-your-own site do not start from the same place.

4. The data model is your trust boundary

The data model is the one layer where a single mistake can expose everything. Point a public site directly at internal objects and it inherits all of it, including fields, relationships, and history entities never designed to live across an external boundary. The scale is not hypothetical. The Loblaw breach disclosed in March 2026 allegedly exposed 75 million records alongside hundreds of millions of related rows. Keep internal objects internal and build a purpose-built exposure layer. Exposure should be calculated, reviewed, and documented, never a default.

5. Your knowledge base can leak what your permissions protect

This is the one many teams never check. Sensitive information ends up in public knowledge articles, whether it is data pulled from case summaries without stripping personal details, internal procedures, or trade secrets, and there is rarely an editorial gate to catch it. Salesforce exposes Knowledge to unauthenticated visitors through the Public channel, and its own guidance is to enable only the minimum channels per article so internal content stays out of public view (Salesforce Knowledge channels). Two traps stand out from the session. Matt described an AI tool that found file-upload instructions for a secured portal sitting in a public article, and once Google indexes a page like that, it effectively never comes back down. Frequent Salesforce Security Office Hours speaker, Beech Horn, added that search can surface fields a user cannot otherwise see, letting someone enter terms and watch which articles return to probe for hidden data. Treat every public article as something an attacker will read first.

6. Execution context can hand a guest the keys to the org

Flows and Apex run in user context, bound by the running user’s permissions, or in system context, which skips native security enforcement. When a guest-reachable flow or an Aura-enabled Apex class declared “without sharing” runs in system context, the guest reaches code that sees everything even though the guest was granted almost nothing. Salesforce’s own guidance is to keep without-sharing code to a minimum and always use “with sharing” on Aura-enabled methods a guest can reach. If you cannot explain why something needs system context, rethink the architecture.

7. You own your custom UI, especially the AI-generated parts

Salesforce base components pass through Salesforce’s own security reviews. Your custom components do not. Vibe coding tools spin up working interfaces fast, but they ship patterns a careful human would not, like sensitive logic pushed client-side where it becomes an injection surface, or accepting a record ID straight from the client so one user can swap an ID into another user’s records. This matters more as offense goes AI-native: 86 percent of phishing attacks are now AI-driven. Review every line of AI-generated code for security loopholes, not just whether it satisfies the ticket, and run a penetration test once the build is live.

Where to start after reading this security resource? 

For the full walkthrough, watch the complete Office Hours episode with Lillie Beiting and Matt Meyers. If you can only do a few things, do these in order. Audit the guest user profile and disable API access if the site does not need it. Run the guest user sharing rule access report to see exactly what a guest can touch. Review what your public knowledge articles actually expose. Restrict the data model to a deliberate exposure layer. Then validate and scan every inbound channel at the point of entry. As Lillie reminded the audience, the goal is to find and fix these gaps before an attacker fixes them for you.

Auditing the guest profile closes the configuration gaps. Protecting what comes through the front door is the other half. EzProtect adds real-time file scanning, malicious URL protection, and phishing detection across every Salesforce entry point, including the file uploads and inbound submissions that public Experience Cloud sites invite by design. See where your exposure is before an attacker does with a risk-free security assessment.

Frequently asked questions

Is Salesforce Experience Cloud secure?

Experience Cloud is secure at the platform level. The breaches making headlines in 2026 were not platform vulnerabilities. Salesforce confirmed that the ShinyHunters campaign exploited customer-configured guest user settings, not a flaw in the product. The platform gives you a strong floor, including private org-wide defaults and restricted guest record access. The risk lives in how each site is configured on top of that floor, which is your responsibility to get right.

What is a guest user in Salesforce Experience Cloud?

The guest user is the single profile that represents every unauthenticated visitor to a public Experience Cloud site. One guest user record exists per site, and everyone browsing without logging in shares it. Because it is your largest and least controllable audience, its object permissions, field-level security, and sharing rules are the first thing to audit and the most common source of exposure.

Does disabling “API Enabled” on the guest profile stop data access?

No. Disabling API Enabled does not fully close the door. If data is shared through the Lightning APIs, an attacker can still query and manipulate records and execute flows and Apex. That said, Salesforce identifies disabling guest access to public APIs as the highest-impact single change you can make, because it closes the Aura endpoint used in the 2026 campaign. Turn it off, then verify nothing else exposes the same data.

Can Salesforce knowledge articles leak data?

Yes. Sensitive information regularly ends up in public knowledge articles, from unstripped personal data in case summaries to internal procedures and trade secrets. Salesforce exposes Knowledge to unauthenticated visitors through the Public channel, and the guidance is to enable only the minimum channels per article so internal content stays private. Once a public page is indexed by a search engine, it is very difficult to fully remove.

What is the difference between user context and system context in Salesforce?

User context runs a flow or Apex within the running user’s permissions, respecting sharing, object permissions, and field-level security. System context skips that enforcement and runs with full access. When guest-reachable code declared “without sharing” runs in system context, a guest can reach data they were never granted. Salesforce guidance is to keep without-sharing code to a minimum and use “with sharing” on any Aura-enabled method a guest can reach.

How often should you run a security review on an Experience Cloud site?

Treat security review as an ongoing cadence, not a one-time launch gate. Configurations that were safe two years ago can become exposures as the org grows and policies change. Tie reviews to your release schedule, re-audit field-level security every time the site expands, and run a penetration test once the build is live.