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 Force.com 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!
page revision: 0, last edited: 01 Jan 2017 23:37