postMessage Origin Validation Bypass in LWC

Executive Summary

LWC components that use window.addEventListener('message', ...) often process cross-window messages for iframe integrations. If the handler trusts message data without strict origin validation, the component can become a cross-origin command or data injection surface.

In managed package deployments, this risk is amplified because subscriber orgs may embed package components into varied page contexts, increasing untrusted frame interaction opportunities.

Salesforce Attack Surface

• LWC message listeners: handlers accepting postMessage events from iframes or parent windows
• Weak origin checks: wildcard trust, suffix matching, or partial string checks on event.origin
• Untrusted iframe sources: dynamic or user-influenced iframe URLs
• Command-style payloads: client-side operations executed directly from message content
• Bridge components: VF-LWC or Aura-LWC integrations forwarding unvalidated messages

Business Impact

• Unauthorized action triggering: forged messages invoke sensitive UI workflows
• Data integrity issues: attacker-controlled payloads alter selected records or transaction context
• Session-adjacent abuse: trusted browser session used to execute attacker-influenced flows
• Cross-tenant trust erosion: managed package integrations appear insecure in subscriber org reviews
• Security review findings: inadequate origin validation is a recurring AppExchange concern

PoC Use Cases

// Vulnerable LWC handler
connectedCallback() {
    window.addEventListener('message', this.handleMessage.bind(this));
}

handleMessage(event) {
    // BAD: weak trust check
    if (event.origin.includes('force.com')) {
        this.selectedRecordId = event.data.recordId;
        this.executeAction(event.data.action);
    }
}

• Attacker hosts page on crafted domain that passes weak origin check.
• Malicious frame posts command payload to LWC listener.
• Component executes unauthorized action based on attacker data.

Testing Methodology

• Listener inventory: find all message event handlers in LWC/Aura/VF surfaces
• Origin check analysis: verify exact-match allowlists rather than pattern-based trust
• Payload abuse: test forged recordId, action, and privilege flags
• Frame control tests: validate behavior with attacker-controlled parent/child frames
• Evidence mapping: capture request chain and unauthorized business impact

Secure Engineering Patterns

• Exact origin allowlist: compare event.origin against strict approved origins
• Schema validation: enforce message structure and allowed command values
• No client-side authorization: treat message payload as untrusted input only
• Context binding: bind message handling to expected event.source where possible
• Server-side gates: enforce authorization in Apex before any sensitive mutation

// Safer handler
const TRUSTED_ORIGINS = new Set([
    'https://mydomain.my.site.com',
    'https://mydomain--c.vf.force.com'
]);

handleMessage(event) {
    if (!TRUSTED_ORIGINS.has(event.origin)) return;
    if (!isValidMessageSchema(event.data)) return;

    // Process only non-sensitive UI state.
    this.selectedRecordId = event.data.recordId;
}

Verification Checklist

• All LWC postMessage listeners use strict origin allowlists
• No wildcard, suffix, or substring origin validation patterns remain
• Message payload schema is validated before use
• Sensitive actions are authorized server-side, never by message content alone
• Regression tests include forged-origin and forged-payload scenarios

Lab Exercises

• Exercise 1: Enumerate all postMessage listeners across LWC/Aura/VF
• Exercise 2: Reproduce weak-origin bypass with controlled attacker frame
• Exercise 3: Demonstrate unauthorized behavior via forged payload
• Exercise 4: Implement exact-origin checks and payload schema validation
• Exercise 5: Re-test and produce security review evidence package