[SalesForce] Database.delete and CRUD permissions

I have an detail Custom Object that has Contact as its master.

My user profile has Read, but not Edit, Delete or Create permission.

When I login as this user I can View the record, but the Edit and Delete buttons do not appear in the record, whereas they do for administrators. This is expected behaviour.

However, I have a Visualforce page "with sharing" where the user can delete this record. I pass an ID recordToDelete through an actionFunction, and then in the controller do

Database.delete(recordToDelete);

as per the docs.

I would expect an Insufficient Privileges method to be displayed for the user who doesn't have delete permission. However, the data is deleted.

Does Database.delete not respect CRUD permissions?

Best Answer

Yeah - based on that wiki, I think you need to check for deleteable in the extension before they can delete the record e.g.

public PageReference deleteLead() {
      // Check if the user has delete access on the Lead object
      if (!Lead.sObjectType.getDescribe().isDeletable()){
        ApexPages.addMessage(new ApexPages.Message(ApexPages.Severity.FATAL,
                                                    'Insufficient access')); 
        return null;
      }

Related Solutions

[SalesForce] Show “Insufficient Privileges” directly when clicking ‘Edit’ (override), not on ‘Save’

You can query the UserRecordAccess object to find out if a particular user has edit access to a record. Something like this should tell you if the particular user has edit access to the particular record.

select RecordId, HasEditAccess from UserRecordAccess where UserId = :UserInfo.getUserId()
and RecordId = :id]

I wrote a blog article about this a while ago that has some more details.

[SalesForce] CRUD permission check Security Review with SOQL queries needed

You should check that the current user has isAccessible() permission on the fields in the WHERE clause as well as any fields in the SELECT clause being returned to the logged in user. The reason why you need to do this check is that Apex will not throw a DML error when accessing fields that the user cannot access, so it is up to you to enforce the platform's permission model.

There is some confusion if your intuition comes from working in the developer console or via the API. The developer console runs in an execute anonymous context in which permissions are enforced. Permissions are enforced in the API as well. Permissions are not enforced in apex code running in your org, so you as the developer need to enforce them. You will not get permissions exceptions.

Also, be aware of the difference between profile perms, CRUD/FLS perms, and record sharing. Profile perms are always enforced but are only refreshed across logins. CRUD/FLS are never enforced which is why you need to make all those .isAccessible(), and isCreatable() calls before accessing, updating, deleting or inserting records. Record sharing is enforced if your class is 'with sharing'.

In terms of implementation, it's up to you as the dev to enforce programmatically whatever isn't enforced automatically by the platform, where appropriate. In some cases you may want to set a field as private/private for sharing and then ignore sharing when accessing the field. This should only be done for custom fields. In the case of sites and guest user access, you may also need to ignore CRUD/FLS, but again this should only be done for custom fields that are in your namespace. For standard fields you must always enforce CRUD/FLS (no exceptions), and you must always enforce sharing in the entry-points to your app (controllers and global classes). Hide the without sharing code in library functions invoked downstream from your entry points.

Best Answer

Related Solutions

[SalesForce] Show “Insufficient Privileges” directly when clicking ‘Edit’ (override), not on ‘Save’

[SalesForce] CRUD permission check Security Review with SOQL queries needed

Related Topic