Insecure Use of High Privilege Methods

This lab explains how misuse of privileged Salesforce platform methods can bypass intended security controls and lead to account compromise, unauthorized actions, or data exposure when invoked without strict authorization and context validation.

Executive Summary

High privilege methods perform sensitive actions such as password operations, user state changes, privileged callouts, or execution in elevated contexts. These methods are not inherently vulnerable, but become exploitable when user-controlled inputs can reach them without robust authorization checks and business validation.

Security review should focus on exploitability: can a low-privilege or untrusted flow trigger a privileged operation outside intended policy?

Salesforce Attack Surface

  • Password and user lifecycle operations: methods that set, reset, or unlock user access
  • Administrative state changes: profile, permission, or role-affecting logic paths
  • Privileged integrations: Named Credential or system-context callouts acting on behalf of users
  • System-mode execution chains: controller and service methods running without effective user constraints
  • Generic utility controllers: methods exposing privileged actions through broad endpoints

Business Impact

  • Unauthorized account control: forced resets, lockout abuse, or session disruption
  • Privilege escalation: low-trust paths invoking admin-equivalent actions
  • Data integrity loss: sensitive updates executed beyond policy boundaries
  • Operational and compliance risk: inability to prove least privilege and change accountability
  • Incident complexity: abuse often appears as legitimate platform behavior in logs

PoC Use Cases

Validate misuse paths using controlled test users and explicit authorization boundaries.

// Illustrative anti-pattern: privileged operation exposed via weak gate
@AuraEnabled
public static void resetAnyUserPassword(Id targetUserId, String newPassword) {
    // Missing object-level/business-level authorization validation
    System.setPassword(targetUserId, newPassword);
}
  • Can a non-admin caller invoke privileged method paths?
  • Can attacker-controlled target identifiers alter other users or records?
  • Are audit trails sufficient to distinguish legitimate admin actions from abuse?

Testing Methodology

  • Map privileged sinks: identify high-impact methods and wrappers around them
  • Trace entry points: locate all Aura, LWC, VF, API, and Flow paths that can reach those sinks
  • Role-based validation: test with constrained profiles and permission sets
  • Input abuse testing: modify target IDs and action parameters to test horizontal/vertical abuse
  • Evidence collection: capture request context, sink invocation path, and unauthorized effect

Secure Engineering Patterns

  • Explicit authorization gates: verify both role permission and business ownership before privileged actions
  • Context binding: bind target entity to authorized actor scope, never trust client-supplied target IDs alone
  • Least privilege execution: isolate privileged code to minimal, audited service layers
  • Defense in depth: pair method-level checks with CRUD/FLS/sharing validation where applicable
  • Operational controls: alerting and immutable audit logs for sensitive method invocation
// Safer pattern: enforce privilege and ownership before action
@AuraEnabled
public static void resetUserPassword(Id targetUserId) {
    if (!FeatureManagement.checkPermission('Can_Reset_User_Password')) {
        throw new SecurityException('Not authorized');
    }

    // Example business validation: caller can only manage users in allowed scope
    User target = [SELECT Id, ManagerId FROM User WHERE Id = :targetUserId LIMIT 1];
    if (target.ManagerId != UserInfo.getUserId()) {
        throw new SecurityException('Target user out of scope');
    }

    System.resetPassword(targetUserId, true);
}

Verification Checklist

  • All high privilege methods are inventoried and linked to authorized use cases
  • Entry points enforce strict authorization before invoking privileged sinks
  • Target resources are validated against caller scope and ownership
  • Regression testing confirms low-privilege users cannot trigger privileged outcomes
  • Sensitive actions are logged with actor, target, reason, and execution context

Lab Exercises

Complete the following exercises to build practical confidence in identifying and fixing privileged-method abuse:

  • Exercise 1: Enumerate high privilege method sinks in Apex code
  • Exercise 2: Map sink reachability from UI/API entry points
  • Exercise 3: Demonstrate unauthorized sink invocation with restricted users
  • Exercise 4: Implement explicit authorization and scope validation controls
  • Exercise 5: Re-test exploit paths and produce remediation evidence