Security
Securing a Visualforce user interface involves controlling access to the objects, the records, and the page itself. Visualforce obeys the object and field-level security rules configured in profiles. Record security is handled by the controller through special keywords in Apex in conjunction with custom code that can be written to enforce application-specific security rules. Access to the page is granted by the user’s profile.
Note
As Visualforce is a Web technology, it’s also critical to guard your Visualforce pages against vulnerabilities native to the Web. This includes Cross-Site Scripting (XSS), SOQL Injection, and Cross-Site Request Forgery (CSRF). There are many built-in features of Visualforce and Apex that address these vulnerabilities transparently to the developer, but it’s a good idea to be aware of them. Depending on the nature of your Visualforce pages, additional effort may be needed to protect against them. For more information, consult the Secure Coding Guideline document published by Salesforce, available at http://wiki.developerforce.com/page/Secure_Coding_Guideline.
Object-Level Security
Access to database objects and fields is determined by the profile and is consistent with the native user interface. This protects the database and maintains the centralized control of data security, but also exposes the user interface to various runtime errors if improperly configured. For example, if the user’s profile denies all access to an object, this object is essentially invisible. When a Visualforce controller attempts to select from it, the page fails with an exception. Other configuration problems are handled more transparently to the user. If the user’s profile lacks edit access on an object and a Visualforce page binds an inputField to that object, it is automatically rendered as an outputField, appropriately blocking user input.
When developing a controller, check that the SOQL, SOSL, and DML operations are fully compatible with the set of profiles expected to use the page. As a developer, you have full visibility to every object and field, but do not assume that your users have the same level of access. Test the Visualforce pages by logging in as a test user or cycling through profiles on a single test user. You can also write unit tests that run under the privileges of a specific user using the System.runAs method, covered in more detail in the “Unit Tests” subsection.
Record-Level Security
Standard controllers always honor the record-level security of the current user. But by default, record sharing rules are ignored by code in custom controllers. These controllers run in a system context, like a trigger.
Note
Record sharing rules are still honored by the methods of standard controllers that have extensions defined, but the code in an extension class itself still runs in system mode.
For example, if a user’s profile grants the user access to a particular object, your custom controller queries it, and your Visualforce page displays the results, the user can read every record in the object, regardless of the sharing settings.
You can change this behavior in the controller code by specifying a security mode in the class definition. Two security modes are available: with sharing and without sharing. The controller definition in Listing 6.17 uses with sharing to configure the controller to honor record sharing rules.
Listing 6.17 Custom Controller Using Record Sharing Rules
public with sharing class MyController {
// the code in this controller honors record sharing rules
}
The without sharing security mode indicates that a class should not obey record sharing rules, which is the default state. You do not need to change this unless your code accesses objects that have record sharing rules defined that you would like to enforce in your user interface. Subclasses inherit the security mode from their parent class, but inner classes do not. In nested calls, where one class calls another class, the current security mode is applied unless explicitly specified.
After a security mode is chosen, no additional work is required. SOSL and SOQL statements automatically return the correct subset of records based on the sharing rules for each object. But if a record is referenced directly that is not shared with the user, such as through a DML method updating a foreign key, a runtime error is thrown. Use a try, catch block around DML methods to make sure that this situation is properly handled.
Page-Level Security
Profiles determine which users are able to use a Visualforce page. Pages must be explicitly enabled for each profile that requires access. If this is not done, users will receive an error page titled Insufficient Privileges when attempting to view the page.
To grant a profile access to a page, go to the Administration Setup and click Manage Users, Profiles. Select the desired profile, scroll to the Enabled Visualforce Page Access section and click the Edit button. Select pages from the Available Visualforce Pages list and click the Add button to add them to the Enabled Visualforce Pages list. Click Save when you’re done.
Note
Users with the Customize Application permission can access all Visualforce pages in the organization.