Introduction

In Salesforce, not every user has access to every object. Some users may be allowed to read data, while others may create, update, or delete records. This control is called object-level security.

When developing Visualforce pages and Apex controllers, Salesforce does not automatically enforce object permissions. Developers must explicitly check object access to prevent unauthorized users from viewing or modifying data. Ignoring this can lead to serious security issues.

What is Object-Level Security?

Object-level security defines what actions a user can perform on a Salesforce object.

● Controls access to an entire object
● Defined using profiles and permission sets
● Applies before record-level access
● Must be enforced manually in Apex

Types of Object-Level Permissions

Object-level permissions include:

● Read
● Create
● Edit
● Delete
● View All
● Modify All

These permissions determine what operations a user can perform.

Why Object-Level Security is Important

Object-level security is critical because it:

● Prevents unauthorized object access
● Protects sensitive business data
● Ensures compliance with Salesforce security model
● Avoids security review issues
● Is mandatory in real projects

How Object-Level Security Works in Visualforce

Visualforce pages can display or modify object data even if the user does not have permission, unless checks are added manually.

● Visualforce does not auto-enforce CRUD
● Apex controllers must check permissions
● UI access does not guarantee object access
● Security must be coded explicitly

Checking Object-Level Security in Apex

Salesforce provides Schema.sObjectType methods to check object permissions.

Read Access Check Example

if (!Schema.sObjectType.Account.isAccessible()) {
    ApexPages.addMessage(
        new ApexPages.Message(
            ApexPages.Severity.ERROR,
            'You do not have access to Account records'
        )
    );
    return;
}

● Prevents unauthorized read access
● Commonly used in controllers
● Exam-important syntax

Create Permission Check Example

if (!Schema.sObjectType.Contact.isCreateable()) {
    throw new SecurityException('No create access on Contact');
}

● Prevents record creation
● Used before insert operations
● Mandatory in secure Apex code

Update Permission Check Example

if (!Schema.sObjectType.Opportunity.isUpdateable()) {
    throw new SecurityException('No update access on Opportunity');
}

● Prevents unauthorized updates
● Used before update DML

Delete Permission Check Example

if (!Schema.sObjectType.Case.isDeletable()) {
    throw new SecurityException('No delete access on Case');
}

● Prevents record deletion
● Important for admin-restricted objects

Real Project Example (Very Important)

Business Scenario

A Visualforce page allows users to create new Account records. Only users with Create access should be allowed to save data.

Secure Apex Controller Example

public class AccountController {

    public Account acc { get; set; }

    public AccountController() {
        acc = new Account();
    }

    public PageReference saveAccount() {

        if (!Schema.sObjectType.Account.isCreateable()) {
            ApexPages.addMessage(
                new ApexPages.Message(
                    ApexPages.Severity.ERROR,
                    'You are not authorized to create Account records'
                )
            );
            return null;
        }

        insert acc;
        return null;
    }
}

● Object permission checked before insert
● Prevents unauthorized creation
● Real-world secure implementation
● Exam-ready example

Using Object-Level Security in Visualforce UI

Object permissions can also control UI rendering.

Example:

<apex:outputPanel rendered="{!$ObjectType.Account.isCreateable}">
    <apex:commandButton value="Create Account" action="{!saveAccount}" />
</apex:outputPanel>

● Button visible only if user has permission
● Improves UX and security
● Common real-project pattern

Object-Level Security vs Record-Level Security

Key differences include:

● Object-level controls access to the object
● Record-level controls access to specific records
● Object-level is checked first
● Both must be enforced

Common Mistakes Developers Make

● Assuming Visualforce enforces object security
● Skipping CRUD checks in Apex
● Only checking record-level sharing
● Hardcoding security logic

Best Practices

Follow these best practices:

● Always check object access before SOQL and DML
● Use Schema.sObjectType methods
● Combine with field-level and record-level security
● Handle security errors gracefully
● Test with restricted user profiles

Exam Key Points to Remember

● Object-level security is CRUD
● Apex does NOT enforce it automatically
● Use isAccessible, isCreateable, isUpdateable, isDeletable
● Mandatory for Salesforce security review

Conclusion

Object-level security is a fundamental part of secure Visualforce development. By explicitly enforcing CRUD permissions in Apex and Visualforce, developers ensure that users can only access objects they are authorized to use. Proper implementation of object-level security is essential for exams, real-world projects, and Salesforce security compliance.

VF Page Beginner to Advance

Object- Level Security in VF Page