Three Steps to Verify Your Experience Cloud Security Settings

Salesforce Architects
Salesforce Architects
3 min readApr 28, 2020

--

Ask An Architect

In our last two articles, we first discussed the three steps to reviewing your data security in Community Cloud and then continued into the advanced configuration of security in Community Cloud. Now that your data is prepared, what’s next? Measurement. Evaluating the security of your Community Cloud implementation is essential to ensuring your previous work was successful, and here are three steps to do just that.

1. Validate Your User’s Experience

Default Visibility Setting

You know what experience you want your users to have, based on the profile permissions you defined. After configuring Organization-Wide Defaults, Object and Field Level Security, and Sharing Rules and Sets, check the access of each profile and ensure it aligns with your expectations. You can do this via the UI by:

If you can access more data than you should or if you cannot access data that you should, make the necessary adjustments to each profile and try again. And while you’re at it, we recommend reviewing each page layout, using Field Level Security to hide or set fields as read-only as needed.

A few more things to note:

2. Custom Code Compliance

APEX Sharing

Warning: A lot can go wrong when using custom code! In particular, Apex classes can be written using the without sharing keyword, which will essentially render all the checks and settings we’ve covered so far useless. Because the risks are high, consider asking a Certified Salesforce Developer to perform reviews of any Apex code prior to moving it to production if you decide to use without sharing in your Apex code.

3. Additional Checks

To confirm your Community security meets your expectations, there are two additional tools you can run.

First, Checkmarx is especially helpful if you’re using custom code because it views both the UI pages and the Apex classes that support them. This tool identifies pages that do not check for the level of access by the running user, or have input fields that allow escape special characters, which could allow an injection attack.

Second, Portal Health Check shows what your users have access to after you have completed your configuration. Because the check does not expose vulnerabilities introduced by custom pages/code, you should use it in conjunction with other tools outlined in this document.

About the Authors

Tom Leddy

Tom Leddy is a Director of Education Services at Salesforce.org. As a certified Salesforce Architect, he advises education industry customers that are undergoing digital transformation efforts to help reshape their organizations and serve their constituents more effectively. He also leads multiple Salesforce.org community efforts, including the Ask An Architect content series and Architect Academy Roundtables series. Tom is a published author, public speaker and marathon runner based in the Chicago area. You can connect with him on LinkedIn, Instagram and Twitter

Carlos Villalpando

Carlos Villalpando is a Senior Manager Advisory Services at Salesforce.org based in the Twin Cities area. He has been working on IT strategy for the last several years architecting, developing and re-engineering processes to make them efficient and aligned with the business that they serve.

Originally published at https://www.salesforce.org.

--

--

Salesforce Architects
Salesforce Architects

We exist to empower, inspire and connect the best folks around: Salesforce Architects.