i do a lot of Salesforce stuff, all of these issues are on Experience Cloud ( the Salesforce portal portfolio ). No one ever looks closely at the "guest user" t

i do a lot of Salesforce stuff, all of these issues are on Experience Cloud ( the Salesforce portal portfolio ). No one ever looks closely at the "guest user" this is basically used for unauthenticated portal pages, even though there isn't a user per-se there's still a session and it maps back to a user and profile ( profile = what controls security for a group of users in Salesforce ). What happens is the guest user ends up with read access on an Object ( SF term for a table ) somehow but it's never surfaced on the portal as a page and therefore never tested/known by the testing/qa team. Then, as an end user curious enough, through some browser request manipulation or address bar manipulation you can access the records for that Object (table). Guest user problems go far deeper than what the article describes and over the years Salesforce has been slowly dialing down what the guest user can have access to. It's an intricate exercise to properly lock down that profile in Experience Cloud (the portal feature portfolio). Guest user aside, privilege escalation attacks are very easy to introduce when writing custom APEX and front-end code. APEX is Salesforce's backend language similar to Java but runs in a system context not entirely constrained by the security settings of the running user. It's very simple for a naive developer to introduce a privilege escalation attack when writing an APEX method that is called from the front-end javascript framework ( LWC or Aura ). This is especially the case when the underlying record access model (think row-level access control in PostGres) is left to defaults or even opened further and not properly locked down. At my firm we have an entire practice dedicated to Salesforce security and require security scans, reviews, and remediation performed by this practice for all implementation projects because of things like this.