1

I am wondering what is Apex Class Access setting in Permission Set used for?

In the documentation - Setting Apex Class Access from Permission Sets - it is said:

These settings only apply to Apex class methods, such as Web service methods, or any method used in a custom Visualforce controller or controller extension applied to a Visualforce page.

My understanding is that all internal users get access to all classes by default. But if the user tries accessing a custom WebService method via API (Workbench) then they need Apex Class Access for their user.

It also mentions Visualforce pages, although if the user has access to VF page they automatically get access to apex classes used by controller/extension.

I am not sure if my assumptions are correct, so it'd be great if someone explained it.

Improve this question
1
  • 1
    I would also love to get a clear and thorough explanation on this, the documentation seems woefully vague.
    – number41
    Commented Jun 8, 2020 at 2:28

1 Answer 1

Reset to default
5

This is old, but since I've been on this topic, it's probably worth explaining, and I hope it helps someone.

Various APIs will enforce or not enforce Apex class access. It depends on your use case.

Custom controllers for Visualforce Pages, for example, the user in context does need to have class access, as it's the first point of entry to the platform. I believe your API enabled (@RestResource) endpoints do as well, so those are the sorts of things where you need to set it. This is granular only to the Class level.

For @AuraEnabled enpoints, this is currently not the case, but there is a security update available now that changes that. For Aura, technically, it's just the one endpoint, /aura that everyone has access to. The client makes a call with parameters specifying the class AND method to be called in the URL (along with the payload in the body IIRC). The platform would put security on /aura but that's hardly useful since essentially everyone has it - the security update will have that endpoint in turn check class access on the requested class when making these calls. Again, this will be granular to the class, but the @AuraEnabled annotation is at the method level.

You are correct though, once your in the platform, in executing Apex code, all security from there is up to the coder essentially. It's in their documentation, any @AuraEnabled endpoint is to be treated as insecure and it's up to the developer to enforce security via custom code, or code to enforce rules based on leveraging their various exposures to their security platform (e.g. protecting SOQL injection, with sharing keyword, Object and Field level permissions via SObject.getDescribe(), WITH SECURITY_ENFORCED keyword, etc.).

This whole section of documentation and its subsections area worth reading and understanding: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_security_sharing_chapter.htm

Developer should assume @AuraEnabled is insecure: https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_apex_auraenabled_annotation.htm

Winter '20 release notes on feature to help secure @AuraEnabled endpoints (which, if you're not ready for, will break stuff): https://releasenotes.docs.salesforce.com/en-us/winter20/release-notes/rn_lc_crucs.htm

Improve this answer

You must log in to answer this question.

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