Salesforce is often viewed primarily as a CRM, but it also serves as a platform for building external-facing web applications. Organizations frequently deploy customer portals, partner sites, internal sites, and marketing landing pages directly on top of their Salesforce database. These sites can have custom URLs and brading and users will not really understand they are using Salesforce. While this eliminates the need to synchronize data with external web servers, it introduces significant data exposure risks if permissions, sharing rules, and access controls are misconfigured.

Salesforce web deployments generally fall into two architectures:

• Experience Cloud sites: Modern sites built using the graphical Experience Builder, running on either Lightning Web Runtime (LWR) or Aura Runtime. Previously Experience Cloud was called “Community Cloud”.

• Force.com sites: Legacy sites constructed using Visualforce pages and custom Apex controllers.

Under the hood, both architectures interact with the same underlying Salesforce platform APIs and database engine and their basic security configuration is very similar.

Salesforce implemented major security guardrails between 2020 and 2021 to restrict default guest user access. However, modern baseline defaults do not prevent security drift. Accumulating technical debt—such as legacy Apex classes, outdated permission sets, and unmaintained custom code—along with routine maintenance and third-party package installations regularly re-introduce over-permissive access controls.

Real-World Exploitation and Threats

Experience Cloud security risks are not just theoretical. There have been multiple publicly documented vulnerabilities and breaches.

In April 2023 Brian Krebs, a renowned Cybersecurity Journalist, wrote an article about many bank and healthcare provider Salesforce sites leaking sensitive information. Salesforce’s response to Krebs was that the data exposures are not the result of a vulnerability inherent to the Salesforce platform, but they can occur when customers’ access control permissions are misconfigured (see Krebs’s blog post).

In January 2026, Mandiant released AuraInspector, an open-source auditing tool designed to inspect Aura framework endpoints. Threat actors quickly weaponized modified versions of the tool to scrape exposed records across hundreds of Experience Cloud deployments (see SalesforceBen covering the attacks).

In August 2026, automated campaigns targeting both Salesforce Experience Cloud and ServiceNow portals came to light, bypassing UI restrictions by directly querying API endpoints (see details on the 560k attack campaign).

Typical Problems with Salesforce sites

Because Experience Cloud applications support custom business logic and API integrations, they require the same secure coding and access control standards as any public-facing web application.

Most vulnerabilities stem from unauthenticated Guest or authenticated Community users receiving excessive object-level or field-level permissions, allowing threat actors to extract records directly through Aura endpoints, UI APIs, or REST endpoints.

Root causes

1. Excessive Guest User Permissions

   • Each site has its own Guest User Profile. Review object granted to those profiles. Only absolutely necessary object accesses should be granted to unauthenticated guest users.

   • Audit and revoke access to unnecessary Setup entities, including unused Apex classes.

   • Enforce the principle of least privilege by removing administrative and system permissions from guest profiles. Guest profiles rarely require system-level privileges.

   • Disable guest file access, asset file visibility, and member list visibility unless strictly necessary for core functionality.

2. Over-Permissive Community User Access

   • Review object permissions assigned to Community User profiles. Only grant necessary access.

   • Audit permission sets assigned to Community Users. Note that User Access Policies (UAPs) may be configured to automatically assign permissions to community users.

   • Review record-level access configurations across Organization-Wide Defaults (OWD), Sharing Sets, and Sharing Rules. Permissions govern object visibility, while sharing mechanisms dictate record-level accessibility.

   • Restrict external authenticated users to records they explicitly own or that are intentionally shared through scoped sharing rules.

3. Apex Controller Vulnerabilities

   • Classes declared with @AuraEnabled methods are publicly accessible via Aura endpoints. Bypassing client UI validation allows attackers to invoke these methods directly.

   • Legacy Apex controllers omitting explicit “with sharing” declarations execute in system context, bypassing object- and field-level security checks. While Summer ’26 (API v67+) defaults omitted keywords to “with sharing”, legacy API versions and explicitly declared “without sharing” classes remain significant technical debt risks that require continuous audit.

   • Dynamic SOQL queries in controllers remain susceptible to SOQL injection if user inputs are not properly sanitized or bound.

Missing mitigations

Locked down permissions and sharing access for community and guest users are critical in making sure there are no data leakage or such issues with an Experience Cloud site. However, there are also multiple security settings and other mitigations that reduce the risk of vulnerabilities and misconfigurations actually being exploitable by attackers.

1. Direct API Access

   • Hiding fields or components in the Experience Builder layout does not restrict API access; data remains queryable via standard platform APIs if object and field permissions permit it.

   • Disable API access for Community and Guest User profiles whenever direct API interactions are not required by business logic.

2. Unrestricted Self-Registration

   • Authenticated Community users often receive elevated permissions compared to unauthenticated Guest users. Unrestricted registration hence effectively elevates guest traffic into authenticated contexts.

   • Enabling public self-registration allows attackers to provision community accounts instantly, gaining access to authenticated API endpoints and internal data models.

3. Relaxed Security Headers & Policies

   • Default protections against Cross-Site Scripting (XSS), Clickjacking, and Content Security Policy (CSP) violations are often relaxed or disabled during site customization.

   • Disabled protections are not automatically vulnerabilities on their own, but they can prevent existing vulnerabilities from being exploited or your site from being used as part of an attack targeting your users.

Log monitoring

Effective threat detection and response requires monitoring key Salesforce event logs, some of which require Event Monitoring licenses:

1. Sites Log: Provides HTTP request records for forensic investigation during incident response.

2. AuraRequests Log: Tracks Aura component framework invocations to detect automated endpoint scraping.

3. Setup Audit Trail: Tracks administrative configuration changes across site settings, guest profiles, and permission sets.

4. API Total Usage: Can be used to identify anomalous API traffic originating from Guest or Community user profiles.

5. Login History: Tracks authenticated community user login trends and flags geographic anomalies or credential abuse.

Takeaways

Salesforce Experience Cloud provides a fast pathway for publishing web applications on enterprise data, but architectural convenience introduces real attack surface risks. Because front-end page layouts do not enforce back-end data access, organizations must continuously audit object permissions, secure Apex controller logic, and make sure important vulnerability mitigations are enabled.