In most cases the platform automatically enforces admin-configured authorization settings, so your job is easy. However, because the platform is flexible, there are certain cases where developers can bypass authorization settings.
To understand why and where this happens, you need to understand the two execution contexts that a Force.com app runs in: user and system.
User context is the default context that you see when you’re interacting with the basic UI in Salesforce. In user context, the current user’s permissions, field-level security, and sharing rules are taken into account as you browse the UI or execute code.
The platform runs in user context when:
- A user browses the application via the standard Salesforce-provided UI
- A user views a Visualforce page that uses a standard controller
- A user views a Visualforce page that references objects with standard object notation
- The platform executes Anonymous Apex via console or API calls
- An application on the platform makes a standard API call
This mode is ideal for developers because it enforces all admin configured authorization settings by default. However, user context can limit what data your custom code can interact with.
To support a wide range of features and richer UI experience, the platform can also execute in system context. In this mode, the platform does not take into account the current user’s permissions, field-level security, and sharing rules during code execution.
Think of this as code executing with elevated privileges, running as root or as an admin. In this mode, applications have access to all objects and fields that are available in the org, including encrypted fields.
The platform executes code in system context in:
- Apex Classes (including web services)
- Apex Triggers
- Apex web services called from the API