The Force.com platform
makes extensive use of data sharing rules. Each object has permissions
and may have sharing settings for which users can read, create, edit,
and delete. These settings are enforced when using all standard controllers.
When using an
Apex class,
the built-in user permissions and field-level security restrictions
are not respected during execution. The default behavior is that an
Apex class has
the ability to read and update all data within the organization. Because
these rules are not enforced, developers who use
Apex must take
care that they do not inadvertently expose sensitive data that would
normally be hidden from users by user permissions, field-level security,
or organization-wide defaults. This is particularly true for
Visualforce pages. For
example, consider the following
Apex pseudo-code:
public class customController {
public void read() {
Contact contact = [SELECT id FROM Contact WHERE Name = :value];
}
}
In this case, all contact records are searched,
even if the user currently logged in would not normally have permission
to view these records. The solution is to use the qualifying keywords
with sharing when declaring the class:
public with sharing class customController {
. . .
}
The with sharing keyword directs the platform to use the security sharing permissions
of the user currently logged in, rather than granting full access
to all records.