1

I have a question regarding Apex class security. I am new to coding so have some questions. My question : Whats the importance of using 'Enabled Apex Class Access' option through profile or class list? For the security reasons, we use Sharing & Non-sharing keyword while writing Apex class. i understand that sharing works in the user mode & non-sharing works in the system mode. But now, lets say that I have given read, create & edit permissions to a user through profile for a particular object but I have used with sharing keyword & apex class is not enabled for that particular profile. How will the apex class behave?

For eg: Today, I have just created a small apex class for testing purpose on a custom mobile object where the discount of 20$ should be given if the brand name is 'Samsung'. So, I have used before insert trigger event & used sharing keyword in my Apex class. Now, the Apex class works fine in my profile as a system administrator but I dont want a particular user to call that code. SoI logged in as another user for testing purpose, and gave him Read, create & edit rights through profile & have not enabled Apex class for his profile. But still if I create a record as another user, trigger works & discount of 20$ is given on the price field. now, I am confused! Actually I dont want user to see the updated price after trigger (thats why have used sharing keyword). So, if sharing keyword complies with security settings in profile & permission sets, than whats the use of this option : enable Apex class under class list or profiles?

Sorry for the long post. Thank you for your help & reading this.

2 Answers 2

3

Do not confuse System Mode/User Mode and sharing.

System/User Modes relate to object and field permissions. When in User Mode, only those objects and fields to which the user has been granted access can be manipulated. This access is granted through CRUD/FLS permissions in the user's assigned Permission Sets (or their Profile, though this is on the way out). This allows selective access to objects and their fields, where that access can be none, read, edit or create and delete for objects and none, read or edit for fields. System Mode ignores these permissions and always has access to all objects and their fields.

In sharing, users can read and/or edit/delete specific records to which they have been granted appropriate access. This access is granted through sharing rules, sharing sets (for certain license types in digital experiences), apex sharing or manual sharing (though these can be overridden by restriction rules).

Apex code currently (as of Spring '24) always** runs in System Mode - it is necessary to use explicit mechanisms to respond to CRUD/FLS permissions (examples include using Security.stripInaccessible, SOQL WITH USER_MODE, etc.).

Apex classes are annotated with sharing, without sharing or inherited sharing. These keywords mean the class does or does not apply sharing access to SOQL/SOSL results returned by queries in the methods within it. There is specific behaviour for the inherited (or unspecified) case. You can read about this behaviour in the documentation.

Apex class access, specified through permission sets (or Profiles), is only important where that apex class is being used as an "entry point" to the system. Entry points include REST web services and Aura Enabled methods. Essentially, they are classes that contain methods that are called from "outside the server", either as a REST API or through the UI, for example.

By way of an example, if I have a class, A, that includes an Aura Enabled method that is called from an LWC, and that method in turn calls a method on class B, to use that Aura Enabled method (and thus allow the LWC to function in the UI) I only need list class A in the permission set for the user. Class B is only called internally and does not need to be listed. You can read about this requirement here.

You'll find plenty of further information about permissions and sharing in the documentation.

**: Anonymous apex runs in user mode.

4
  • 1
    N.B. - Documentation on VF is inconsistent - Visualforce Page Security says that if user has page access, they automatically get controller access; whereas Set Apex Class access from Permission Sets states the opposite. And for invocable apex - access to the flow is the permission you need (I think) unless calling the invocable from the REST API (where you need access to the class)
    – cropredy
    Commented Jan 11 at 18:20
  • Fair comments. Want me to work those into the answer itself @cropredy?
    – Phil W
    Commented Jan 11 at 18:24
  • sure - if you think I'm correct; invocable was such a mess - first, no class access required from Flow, then class access required due to a Release Update, then Release Update was withdrawn. It's been a while since I did VF but I'm pretty sure you only need page access.
    – cropredy
    Commented Jan 11 at 18:34
  • I will see of I can test these items and update once done.
    – Phil W
    Commented Jan 11 at 18:55
0

Regarding your first question, you can read about here sharing documentation.

For your example, it's not working because triggers are ran in system context, thus having all the permissions. You can play more with that here: execution context trail

Hope this helps.

You must log in to answer this question.

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