Experience Cloud Developer Guide

Get Up to Speed with Experience Builder Sites
Develop Experience Builder Sites: The Basics
Brand Your Aura Site
Update a Template with the Theme Panel
Use the CSS Editor for Custom CSS
Use Custom Fonts in Your Experience Builder Site
Customize the Theme Layout of Your Template
Use Expressions to Add Dynamic Data to Aura Sites
Configure Swappable Search and Profile Menu Components
Ensure Custom Components in Orgs with Experience Cloud Sites Are Secure
Develop Secure Sites: Authenticated and Guest Users
Develop Secure Sites: CSP, LWS, and Lightning Locker
Add Pardot Tracking to Your Experience Builder Site
Use a CMS with Your Experience Builder Site
Report on Deflections: The Deflection Signals Framework
Avoid Deployment Issues When Moving to Enhanced LWR Sites
Considerations for Deploying Authenticated LWR Sites
ExperienceBundle for Experience Builder Sites
PDF

Note: This release is in preview. Features described here don’t become generally available until the latest general availability date that Salesforce announces for this release. Before then, and where features are noted as beta, pilot, or developer preview, we can’t guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available products and features.

Ensure Custom Components in Orgs with Experience Cloud Sites Are Secure

Developers can customize functionality and business logic in Experience Cloud sites by using custom components. As with any custom solution, developers must be aware of potential security-related pitfalls. Bypassing built-in defenses can expose sites and orgs to security risks.

For example, if a developer stores sensitive data as text in a custom component’s definition, the data can potentially be exposed. Such an exposure can happen when Digital Experiences are enabled in the org, the org has custom components, and the custom component’s developer name is known. Exposure can occur whether the site is public or private.

Data exposed can include:

  • Sensitive information stored as text in the component definition
  • The complete component definition of the component including HTML, JavaScript, and CSS files
  • Names of any other components included in the component definition
  • Any Apex controller and method names used in the component definition

Such data can be exposed for any custom component in the org, whether they’re used in the Salesforce org, on an Experience Cloud site, or when unused.

Take the following steps to decrease risk of data exposure in custom components.
  • Review the component definitions in all your custom components in the org
  • Avoid storing any sensitive data in component definitions. Sensitive data can include personally identifiable information, company confidential information, or any information deemed sensitive to your business and customers
  • Review all your custom controllers and ensure that only required user profiles have access to them
  • Ensure that only required methods are exposed using @AuraEnabled
  • Use a naming convention for custom components that is complex and unique to your org