Session Token Leakage in Outbound Messages

Executive Summary

Session IDs are bearer credentials. If they appear in outbound integration flows, browser-visible responses, debug logs, or third-party callbacks, attackers can replay them to impersonate privileged sessions.

Managed package integrations are especially sensitive because token leakage can propagate outside Salesforce trust boundaries into partner systems and observability pipelines.

Salesforce Attack Surface

• Visualforce exposure: direct rendering of $Api.Session_ID in pages or scripts
• Apex leakage: UserInfo.getSessionId() included in debug logs or outbound payloads
• Integration headers: SessionID sent to external endpoints where storage is uncontrolled
• Client-side bridging: session-bearing data passed via JavaScript, postMessage, or URL parameters
• Monitoring pipelines: leaked tokens in log aggregators, error trackers, or proxy traces

Business Impact

• Account impersonation: attacker reuses leaked SessionID to call Salesforce APIs
• Unauthorized data access: API queries run under victim session context
• Privilege abuse: admin sessions leaked through troubleshooting logic become high-value compromise paths
• Compliance impact: token leakage can violate customer security and audit controls
• Security review failure: AppExchange review flags unauthorized SessionID retrieval or exposure patterns

PoC Use Cases

// Vulnerable anti-pattern
@AuraEnabled
public static String debugSessionContext() {
    String sid = UserInfo.getSessionId();
    System.debug('Current Session ID: ' + sid);
    return sid; // Exposed to client
}

// Vulnerable outbound pattern
HttpRequest req = new HttpRequest();
req.setEndpoint(externalEndpoint);
req.setMethod('POST');
req.setHeader('X-Session-Id', UserInfo.getSessionId()); // Token leakage to third party

• Attacker retrieves leaked SessionID from UI/log/third-party trace.
• Attacker replays token against Salesforce REST or Tooling APIs.
• Unauthorized API activity succeeds within leaked session scope.

Testing Methodology

• Source discovery: identify all uses of $Api.Session_ID and UserInfo.getSessionId()
• Sink mapping: trace where token values are returned, logged, or transmitted externally
• Replay validation: verify whether leaked tokens are usable in realistic API calls
• Context analysis: test leakage under low-privilege and high-privilege users
• Control verification: confirm masking/redaction/omission in logs and outbound telemetry

Secure Engineering Patterns

• Never expose SessionID: do not return, render, or transmit raw session tokens
• Tokenless integration design: use Named Credentials and OAuth scopes instead of session passthrough
• Logging hygiene: redact bearer tokens and security-sensitive headers at source
• Server-side trust boundaries: keep authentication artifacts inside Salesforce-managed channels
• Detection controls: alert on SessionID regex patterns in logs and response bodies

// Safer diagnostic pattern
@AuraEnabled
public static String debugSessionContext() {
    // Return non-sensitive trace ID instead of credentials
    return 'trace-' + String.valueOf(Crypto.getRandomLong());
}

Verification Checklist

• No references to $Api.Session_ID are rendered in UI-visible pages
• UserInfo.getSessionId() is not logged, returned, or forwarded externally
• Outbound integration flows avoid session token propagation to third-party systems
• Log redaction policies block credential leakage across observability tools
• Replay testing confirms leaked token paths are fully remediated

Lab Exercises

• Exercise 1: Locate all SessionID sources in VF, Apex, and integration code
• Exercise 2: Trace leakage sinks across UI responses, logs, and outbound HTTP calls
• Exercise 3: Demonstrate token replay impact in controlled API tests
• Exercise 4: Replace leakage patterns with secure integration and diagnostic designs
• Exercise 5: Re-test and produce remediation evidence for AppExchange review