CRUD/FLS Violations

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)
  • Integrity loss: unauthorized create/update/delete operations
  • Compliance violations: exposure of regulated data
  • Privilege escalation: low-privilege users performing higher-privilege actions

PoC Use Cases

// 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