This article was recently published and caught the eye of our leadership team: https://krebsonsecurity.com/2023/04/many-public-salesforce-sites-are-leaking-private-data/

The article recommends using this app to check for vulnerabilities: https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FR6GaUAL&placement=a0d3u00000B363BAAR&tab=r

Generally our communities don't use the out of the box profiles and we don't grant guest users access to anything (except the basics like login page provided by sfdc).

The report from this app seems to reflect that just fine. But there is a large section on ApexClasses that may or may not include AuraEnabled methods all flagged as potential risk. Nearly all of these come from managed packages.

My questions are:

  1. None of the guest user profiles have access to these apex classes assigned at the profile level so how are these profiles even able to see those classes?
  2. The wording suggests that not having access is actually a problem:

AuraEnabled Apex Classes: The report will highlight any class with potential risks that is: 1) AuraEnabled or maybe AuraEnabled (If part of a managed package and the report cannot read the code within the class) 2) If the Guest User Profile does not have access to the class

To me, this is the opposite of a problem, we don't want guest users to have access to the class so why are these flagged as potential risks?

Unfortunately an article was published and caught the eye of our leadership, I can't provide them a report with 10,000 potential risks that may not actually be risks.

2 Answers 2


I think the auraenabled methods would have been a potential risk before the release update : https://help.salesforce.com/s/articleView?id=release-notes.rn_lc_restrict_apex_guest_users.htm&release=224&type=5

So, if the auraenabled methods are not accessible by the guest user, it should be good.

There is similar appexchange package User Access Report which you can use (https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FYkDDUA1&tab=d). You can use this to scan for all profiles, including for guest user.

The output of this package does NOT show the auraenabled methods that are inaccessible by guest user as potential risk.

  • Selected as the correct answer. I spoke directly to the dev of the original package and he said the same thing and that the package was no longer being maintained and pointed me to the second package which no longer performed that check.
    – gNerb
    May 17, 2023 at 20:23

The package is more of a data leak testing tool, not strictly just a security testing tool. In other words, it is expected that it will have full access to (a) view the source code, and (b) be able to execute the code arbitrarily to determine data leaks. You must set up the Guest User to have full access to every class in order to properly check for leaks and security risks.

Managed packages must always be flagged, because of Salesforce's IP protection for managed code. Your own code must be runnable to verify data leaks. This is important, because it lets you see what a guest can access if, for example, an administrator accidentally grants access to the class later. If you don't grant access, security can't be properly verified, which is why they're flagged as potential risks.

That's because, at the end of the day, anyone with access to a class may be able to run it (because that's how Lightning's API works), so you want to make sure that if security gets messed up somehow, the data still remains safe. Many data leaks happen because of security slip-ups in addition to vulnerable code.

Once you're done testing, remember to revoke access to those classes if you don't need them enabled. You should still fix any noted problems to avoid data leaks in the presence of accidentally enabling these classes in the future, which is easy enough to do, and hard to detect without a rigorous testing regimen.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .