Experience Cloud Security for Architects

Secure architectures help ensure that users accessing your system are who they say they are, allow access to only necessary data, and protect data within the system from being compromised. — Salesforce Well-Architected — Secure

Security is the first topic we cover in the Salesforce Well-Architected framework because protecting your organization’s data has to be the highest priority for any solution you design. You won’t be able to establish trust with your customers if your solution isn’t secure. Implementing Experience Cloud increases the need for security architecture and governance since Experience Cloud sites can make data from your Salesforce org accessible to users outside of your organization.

Making this data available is usually a huge value-add for an organization. Providing your customers with a portal they can use to check the status of an order or service request is likely to improve satisfaction and loyalty, for example. But since your org likely contains a combination of information that you’re ok with external users having access to and information you would never want to share with anyone outside of your organization, you’ll need to be extremely careful about the data you expose in Experience Cloud. To do this properly, you should follow three steps:

1. Set security policies for your organization
2. Design, Build, and Test your Security Model
3. Review regularly and adjust as needed

Set Security Policies for your Organization

A significant number of data breaches are caused by someone gaining access to an application or website, either through anonymous (guest) access or by logging in with a set of stolen (or sometimes even legitimate) credentials and playing around with field values and URL parameters. Their typical goal is to uncover flaws that will give them access to data they shouldn’t have access to. The Salesforce platform contains a variety of security features that will prevent this type of unauthorized access, but they’ll only be effective if you configure them correctly.

Your organization’s data requirements will be unique based on a variety of factors including your industry, customers and the types of services you provide. For example, if you work for a shop that repairs automobiles, it might be a good practice to let members of the same household see historical data about what types of services have been performed on family vehicles, but if you work for a medical provider, allowing family members to see historical data about each other’s doctor visits without their consent would be illegal. So before you build your security model, you’ll need to:

• Make sure that you have a thorough understanding of the data you’re storing in your org, including which elements contain personal information that can be used to identify your users.
• Understand any legal or industry regulations your organization is subject to.
• Identify the different personas who may need to access your org’a data.
• Identify the conditions under which each persona can have access to a particular data element (i.e. authorized users must access the site from an approved IP address and will only be able to view cases where they’re listed as the primary contact).
• Document this information as a set of security policies for your organization. Use the Salesforce Well-Architected Security Policy Template to document your policies and ensure that you haven’t overlooked anything.

Design, Build, and Test your Security Model

Once your security policies have been set, the next step is to design your security model accordingly. Use the patterns and anti-patterns outlined in Salesforce Well-Architected — Secure as guidelines. Here are some specific considerations for Experience Cloud. You can also find these in our Experience Cloud Security Checklist.

• What users can see in an Experience Cloud site depends on their user type. Review this table to make sure you understand what each type of user can see and do within your site and assign licenses accordingly.
• If you use Guest User Profiles to let unauthenticated users access your site, make sure they only have the minimum amount of access needed for basic activities like viewing knowledge articles or general information about your organization. For everything else, you should require users to create accounts, which will allow you to track and audit their activities. Take a look at the Additional Resources section below for links to best practice documentation related to guest user access.
• Use the Guest User Sharing Rule Access Report to review the data guest users have access to and make sure you aren’t sharing more information than you intended to. Keep in mind that simply removing fields from the UI of your Experience Cloud site won’t be enough to protect it from potential exposure and that you should restrict it at the object and field level instead.
• Always set External Orginazation Wide Defaults to private unless you have business justification to change them. Use Sharing Rules and Sharing Sets to open up record access at a more granular level.
• Never give Guest Users the API Enabled permission without business justification. If you want to give it to authenticated users, determine if it’s possible to restrict the IP addresses they can connect to your site from.
• Use Permission Sets and Permission Set Groups to control access to objects and fields. Never assume that a field is inaccessible simply because you’ve removed it from the UI in an Experience Cloud site.
• Use the With Sharing keyword for all code that accesses data or performs data operations. In addition to potentially exposing your data, not using With Sharing can also expose objects that Experience Cloud users shouldn’t have access to, which would violate your licensing agreement.
• Clickjack Protection is enabled by default in all newer orgs. In older orgs, you may need to verify that it’s enabled. Clickjacking is a type of attack that tricks users into clicking links or other controls that appear to be safe. Without Clickjack protection enabled, hackers can create hidden iFrames that point to your Experience Cloud pages and allow them to steal sensitive data when a visitor clicks one of their elements, so it’s imperative to make sure your site is protected. Review the rest of the Session Security Patterns and Anti-Patterns outlined in Salesforce Well-Architected as well.
• Less common but still important: if you’re using custom pages, there are some special security considerations you should review here Also, if your Experience Cloud site still contains Visualforce pages, you should plan to migrate off of them as soon as possible.

Once you’ve designed and built your security model, the next step will be to verify that it’s working correctly. Make sure you have a testing strategy in place that requires testers to access your site as every type of authenticated and unauthenticated persona you’ve identified. They should verify that they can only access exactly the data they are supposed to be able to access and nothing more. Additionally:

• To check for URL Hacks, access your Experience Cloud site as both an authenticated user and a guest user and append the following parameters to the end of the domain name in your browser’s address bar. They should all generate a Page Not Found error. If they don’t, double check your external OWDs to make sure they’re set to private.
• /001 (Accounts)
• /003 (Contacts)
• /005 (Users)
• /500 (Cases)
• Portal health check reports show your security-related portal settings and provide information you can use to improve your security model.
• There are a number of third party organizations that offer penetration testing for a fee. If you want to work with one of these organizations, make sure their processes comply with the Salesforce Security Assessment Agreement.

Review Regularly and Adjust as Needed

Regardless of whether you’re using Experience Cloud or not, creating a good security strategy will never be a “set it and forget it” activity for a variety of reasons:

• Your business needs will evolve over time and you may have to adjust the data your users have access to as a result.
• The Salesforce platform will evolve over time and you may want to take advantage of new security features as they become available.
• The techniques hackers and cybercriminals use to gain unauthorized access to your data will evolve over time and you’ll want to stay vigilant against them.

You can address these three concerns by conducting regular reviews of your security policies and configuration. The cadence itself will vary from organization to organization but you should aim for annual reviews at a minimum (or more frequently as needed). When you conduct your reviews, ensure that there haven’t been any organizational changes that will affect your policies and that there haven’t been any process or platform changes that will affect your security model itself. If you do need to make any adjustments, you should prioritize them as they can affect the safety of your organization and its data.

Additional Resources

• Review Guest User Object Access Levels for Sites
• Guest User Security Policies Enforced
• Site User Visibility Best Practices for Guest Users
• Best Practices and Considerations when Configuring the Guest User Profile
• Guest User Record Access Development Best Practices
• Experience Cloud Security Checklist
• Well-Architected Security Policy Template
• Salesforce Well-Architected — Secure
• Three Steps to Reviewing your Data Security in Experience Cloud
• Secure your Data in Experience Cloud with Advanced Configuration
• Three Steps to Verify your Experience Cloud Security Settings