This lab teaches how to identify and fix object-level and field-level access control gaps in Apex so runtime behavior matches the intended Salesforce permission model.
Executive Summary
CRUD and FLS vulnerabilities occur when Apex runs in system context and returns or modifies records beyond the calling user's privileges. The issue is not only data visibility; it also includes unauthorized updates, deletes, and workflow side effects.
Salesforce Attack Surface
SOQL queries returning restricted fields without enforcement
DML operations executed without object-level permission checks
Reusable service layers invoked by multiple UI/API entry points
Apex REST and integration endpoints returning sensitive fields
Controller logic that assumes profile-based access without verification
Business Impact
Confidentiality breach: unauthorized access to sensitive fields (PII, financial data)
// Vulnerable field exposure
public List<Account> listAccounts() {
return [SELECT Id, Name, Salary__c, SSN__c FROM Account];
}
// Vulnerable delete action
public void removeAccount(Id accountId) {
delete [SELECT Id FROM Account WHERE Id = :accountId];
}
Both examples can violate least privilege if field and object permissions are not explicitly enforced.
Testing Methodology
Review Apex query/DML paths and identify missing enforcement points
Test with constrained profiles and permission sets
Validate both read exposure and write/delete capability
Correlate findings with business impact and data classification
Capture before/after behavior to verify remediation quality
Secure Engineering Patterns
Use WITH SECURITY_ENFORCED where appropriate for read paths
Use explicit CRUD checks before DML operations
Use Security.stripInaccessible to sanitize returned/mutated fields
Adopt user-mode patterns where possible for data operations
Centralize authorization checks in shared service layers
// Safer pattern
if (!Schema.sObjectType.Account.isDeletable()) {
throw new SecurityException('Insufficient permissions');
}
delete [SELECT Id FROM Account WHERE Id = :accountId];
Verification Checklist
Read paths enforce field/object constraints for each profile class
DML paths verify create/update/delete permissions before execution
No sensitive fields returned to unauthorized users
Automated tests cover denied-access and least-privilege scenarios
Security review artifacts include exploitability and fix validation
Lab Exercises
This lab includes hands-on exercises to practice identifying and fixing CRUD/FLS violations in Salesforce code paths:
Exercise 1: Identify object and field authorization gaps
Exercise 2: Implement enforcement in vulnerable query paths
Exercise 3: Add pre-DML CRUD checks and failure handling
Exercise 4: Validate behavior with restricted test users
Exercise 5: Build regression tests for access-control integrity