Public portals built on Salesforce remain a steady target for attackers. Salesforce is clear about the cause: not a vulnerability in the platform, but guest user permissions that have been set too broadly. If nobody has reviewed the permissions of your Experience Cloud guest user, you may be sharing more records than you intended. This article walks through the settings you can check yourself.

What a guest user can and cannot do by default

The guest user is the profile every visitor uses before logging in. Salesforce has tightened the baseline considerably over the past few years:

  • The Secure guest user record access setting is enabled in every org with Experience Cloud sites and cannot be turned off.
  • The external org-wide default for guest users is always Private.
  • A guest user can never hold more than read access, and cannot be a member of a public group or a queue.

The only way to show records to a guest user anyway is a guest user sharing rule, and that is exactly where things go wrong. Such a rule grants immediate, unlimited read access to every record matching its criteria, to anyone visiting the site. A criterion written years ago for twenty product records can easily cover a far larger slice of your org after a few years of data growth.

Four settings to review now

  • Your guest user sharing rules. For each rule, check what the criteria say and how many records fall under them today, not how many did when the rule was created. If you cannot justify a rule, remove it.
  • Object and field permissions on the guest profile. Start from no access and only make exceptions you can explain. Where access genuinely is required, keep it at Read at most.
  • Self-registration. If your site does not need visitors to create their own accounts, turn it off under Setup, All Sites, Workspaces, Administration, Login & Registration. If you do need it, make sure the registration handler runs with sharing, assigns the most restrictive profile available, and requires email verification.
  • Public API access on LWR sites. The Allow guest users to access public APIs preference sits in Experience Builder under Workspaces, Administration, Preferences, and it opens the UI API to guests. Be careful: many standard components depend on it, so test that your site still works as intended after switching it off.

Why this is not a one-off check

Permissions drift slowly. A new site goes live, a component needs read access to one more object, someone enables a sharing rule to test something and leaves it. Each step is small and defensible on its own, but together they change the picture. Salesforce offers the Authenticated and Guest User Access Report and Monitoring package on AppExchange, which shows which records are actually being shared with guest users. Put that check on a fixed schedule, for example every quarter and whenever a new site goes live.

Have your org properly reviewed

This kind of review mostly needs someone to work through it systematically, with a sense of what is normal in your org. That is what our consultancy does: examine how permissions are structured and record what does and does not hold up. If you run public portals, our Experience Cloud page is worth a look as well.

Want to know where your guest users stand? Get in touch and we will schedule a walkthrough.