Salesforce Developer Security Authorization Basic


// Salesforce - Developer - Security - Authorization Basics:

How do the various configurations for FLS / CRUD / Sharing relate to a developer 
working on the platform? 

1. Well written Apex and Visualforce will respect all platform configured 
   authorization controls.

   a. No extra records are visible
   b. No extra fields are visible
   c. CRUD privileges derived from the users profile  & permission sets

2. Poorly written Apex and Visualforce can act as a back door to administrator 
   configured authorization.

   a. Many extra records potentially visible
   b. CRUD not respected by code.

A common developer mistake is not understanding the different contexts in which 
their application may be performing. This can lead to disastrous results.  The 
primary Salesforce execution contexts are:

1. User Context: The current user’s permissions, field-level security, and 
   sharing rules are taken into account during code execution.  

   a. The user will encounter this context in the following places:

      1. Browsing the application
      2. Viewing a Visualforce page  with a standard controller
      3. Executing  anonymous apex in the console
      4. Making a standard API call
      5. Executing Apex via the executeanonymous() API call

   b. No additional security controls are required since all controls are 
      enforced by this context.

2. System Context: The current user's permissions, field-level security, and 
   sharing rules aren’t taken into account during code execution.

   a. The user will encounter this context in the following places:

      1. Apex Classes (including web services)
      2. Apex Triggers
      3. Apex web services called from the API

   b. Additional controls are required in code that runs in system context since 
      none of the standard controls are checked.

   c. Note: All objects and fields are available, including encrypted fields.

From a security perspective, user context is preferable because user access 
controls are maintained throughout the transaction. This is why user context is 
in place for standard pages, and Visualforce pages built on standard 
controllers. But this rigidity is not always a fit for custom business 
processes and applications. Apex and Visualforce applications often require 
permissions beyond the scope of a user's access to provide the necessary 
flexibility. This is why they run in system context. This flexibility , granted 
to the developer, must be used thoughtfully and carefully. With great power 
comes great responsibility!
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License