The background
In August 2022, I raised a case with Salesforce Tech support covering an issue I found with Salesforce Aura Communities (now known as Digital Experiences or Experience Cloud) while doing an assessment on a customer's Salesforce org. The issue was that you are able to modify the Community URL to see standard Salesforce pages - Account, Contact, User, etc. This would not really be an issue, except that the admin has not expected you to see the standard pages as they had not added the objects associated to the Aura community navigation and therefore had not created appropriate page layouts to hide fields that they did not want the user to see. I am now publishing this to help Salesforce Customers protect their data as I was told it was not a bug. From the Salesforce Tech support side, I can see their argument that I am only seeing the data allowed by my profile, permission set(s) and sharing settings allow, however I still believe that the Salesforce Admin who configured the community, did not expect me to be able to get to these pages and see the data. In a perfect world, all Admins will have created page layouts for each profile, including Community profiles, however I do not believe that they would know that they need to.
Please upvote this Salesforce Idea to see if Salesforce will consider enhancing existing capabilities to block Salesforce Standard Pages in Aura Communities.
The issue in a nutshell
Anyone with access to a Salesforce Aura community can easily change the URL by using publicly available information (see details in the How to Replicate section below) and gain access to screens that the company's Salesforce administrator did not explicitly allow and see data that they may not have been supposed to see, even though their data access permissions allowed it. If the administrator also set the external sharing incorrectly for an object, all of the data in that object would be accessible to everyone with permission to see that object courtesy of their profile/permission set(s). There is a setting that stops the ability to see standard Salesforce pages in a community, however it only works for VisualForce communities. There is a workaround I have found using URL redirects to stop this URL change working.
The issue in detail
As an example, in a standard Salesforce Developer org, the standard Contact page layout shows birthdate and home phone number. As a community user, I have a contact record that belongs to an account, and by default, all my colleague's contact records are under the same account, so according to Salesforce default sharing rules, I can see my account and all associated contact records. Now, let's say my CEO is not a user of the community, however I am. I log into the community, use the URL modification to get to my associated contact record - from there I am able to navigate to the Account and from there the Contact related list and I can see all the contacts associated to my account. I can now navigate to my CEO's record and have a look and see his birthdate and home phone number. This is all fine according to the sharing model and my permissions, however the community was not set up to show me any account or contact records, so in my opinion, I should not be able to see this data... There are a few things that need to align to get this to happen: the list views need to be shared with external users, and the Salesforce administrator needs to have not created page layouts specific to the community profile. However in my experience, these settings are left as default in most Salesforce orgs.
If the Salesforce administrator also misconfigured the external sharing setting for some objects and set them to public read (or public read/write), then all the community users could see all the records (and update them in the case of public read/write) in the affected objects if their profile/permission set(s) gave read access to the affected objects...
Having external sharing set to public read is extremely bad practice, and the free Salesforce Optimizer tool and the free Portal Health Check, both in the Setup area of your Salesforce org, highlights this.
I have found the external sharing set incorrectly for Contact and Account objects at three of my approximately 40 customers for which I have done assessments - that's nearly an 8% hit rate of communities where any community user can see all of the data in the Contact and Account objects because their profile/permission set(s) gave them read access to the objects.
My guess is that the vast majority of Salesforce Aura communities have this issue and a reasonable subset have the external sharing misconfiguration issue where all users can see all records in affected objects.
There is a setting in the metadata for Communities (aka CustomSites) called allowStandardPortalPages which defaults to true. In a VisualForce community, setting this to false will stop the URL change issue from happening, however with Aura communities, it does not do that. This is due to the fact that the Aura Community and the VisualForce Community are completely different and the Aura Community does not use that setting at all. The Salesforce documentation for this setting says this:
When enabled, authenticated users in this site can access standard Salesforce pages as allowed by their access controls. When disabled, authenticated users in this site can't access standard Salesforce pages, even if their access controls allow it. If your site serves only Visualforce pages, disabling this setting helps add a layer of access protection to your site. This field is available in API version 39.0 and later.
This led me to raise the case as I believe that it should work for all communities. That is the Salesforce Idea I have created to get the change made - please upvote it.
How to replicate the issue in your community
Log in to your community. Use the Object Prefix shortcut which is explained in this article on Salesforce Ben to take you to the object home page. This works in Classic UI, Lightning UI and also Aura Communities. The reason I believe this happens is that Aura Communities share a lot of capabilities with internal Salesforce Lightning UI.
The Object Prefix shortcut is this: edit the URL and change the /s/ and any following characters to /003 and hit ENTER. You will be taken to the Contact Object home page which will probably be the Recently Viewed List View, now change the List View to All Contacts. If the external sharing model has been misconfigured, you will see all Contact records, otherwise you will just see all the contacts that are in your account (or allowed by your profile/permission sets and sharing rules). If your profile/permission set(s) do not give you access to Contacts, try Accounts, Cases and Users. If none of those work, then your profile/permission set(s) have quite restrictive permissions which is excellent.
UPDATE: 31 July 2023: You can also get to the related lists by using the actual object name in this format: /s/recordlist/XXXXXX/Recent where XXXXXX is the record name (Account for example).
After you are into a standard page, you can navigate as you would anywhere in the system. You are obviously limited to navigating to the objects and fields that are configured in your profile and permission set(s). This works because Salesforce has always had URL "shortcuts" - if you remove everything after the first / in the URL and replace it with a record ID, it will take you to that record, so /0015h00000xv2jkAAA will take you to the account with that ID. This is documented here, here and here. How do I know it is an account? As explained in the Salesforce Ben article, the first three letters in any Salesforce record ID is the object it relates to - 001 = Account, 003 = Contact, 005 = User, etc. You can find these codes by running a report on the Entity Definition object (you need to create a custom report type first) and display Master Label, Key Prefix, Internal Sharing Model and External Sharing Model. The Key Prefix is the 3 character Object prefix. The report above will also assist in seeing any objects whose default external sharing model is set to Public.
How to work around the issue
The URL Redirect capability in Salesforce's Community Builder is the way I have found to stop the URL change issue from occurring (see this help article for background on the URL Redirect feature).
This needs to be done in your Sandbox first to validate it does not break anything else and when you are happy, you can do the same in production.
Go to the Setup area in your Salesforce org, search for Digital Experiences and then click the All Sites link. Then click the Workspaces link beside the community you want to protect, then click on the Administration tile, on the menu that appears, click the last entry (URL Redirects) and load a CSV file that contains rows that redirect from /XXX to / where XXX is the Object prefix.
I would suggest running the report mentioned above, getting all the prefixes and creating a CSV file to stop all of them It is a bit of a sledgehammer to crack a walnut solution, however it is the easiest. The layout of the file looks like this:
/001,/
/003,/
/005,/You will need to edit the file that you exported from the report to remove punctuation, duplicates and any entries with a # in them, then make it look like the above. Remember that you will need to do this again every time you add more objects to your org.
UPDATE: 31 July 2023: you will also need to use the name of the object to generate a second list with the /s/recordlist/XXXXXX/Recent redirecting to /.
/s/recordlist/Account/Recent,/
/s/recordlist/Contact/Recent,/
/s/recordlist/User/Recent,/Since any new upload overwrites the current settings, you will need to concatenate the two lists and upload as one file.
I publish these blogs on Medium as well. To get notified of these, please subscribe.