Salesforce Communities Security Issue — Update
TL;DR; Do not use Public Read or Public Read/Write as the Sharing Setting for External users or use sharing rules to do the same thing
You may have read my previous story about security issues surrounding Salesforce Communities (aka Digital Experiences, Portals, …) where I cover how to stop a simple hack allowing external, authenticated users to see all other user’s data.
The reason the hack even works is that the objects in the Salesforce environment have Public Read or Public Read/Write sharing settings for External users and are included in the profile/permission sets for the users.
The solution I gave to prevent the simple hack does not really solve the issue — there is a more complex hack that bypasses every bit of UI security you try to put into place and will allow the hacker access to every record in every object that has Public Read or Public Read/Write sharing settings for External users, or has sharing settings that grant the same permissions and are included in the profile/permission sets for the users.
I am not going to cover how this hack works, however details of how to do it is out in the public domain and is most likely being used in the wild.
To solve this issue, please just stop using Public Read or Public Read/Write sharing settings for External users and do not use sharing rules to do the same thing. If you have this set now, fix it in your next release cycle. Changing the sharing settings is technically very easy to do; however, the issue will be in making sure the community still functions the way it should and this will, more than likely, need code/configuration changes to correct. But do not put it aside — if you have Public Read or Public Read/Write sharing settings for External users, your data is unsafe! It is also unsafe if you have used sharing rules to do the same thing — grant access to all external users.
Yes, you need to have the object in the profile/permission set for the external users for the breach to occur; however, if you rely on this, you are accepting a huge risk. Defence in depth is the way forward — do not have the sharing set incorrectly, do not have these objects in the profile/permission set of external users. Now you have two layers of protection. As I said above, your data is unsafe if you have permissive sharing. Relying on a just a profile or permission set to protect your data is very unwise.
If you do not have Event Monitoring (and are not backing up the logs) you cannot tell if it has been used against you already.
To tell if you have this setting in your environment, please run the Salesforce Optimizer found in the Setup area of your Salesforce org.
