feat(lightning-message-channel): flag message channels exposed to every namespace

[cclabsnz]

Adds check 93. Came out of asking whether Lightning Message Channels — server-defined metadata, consumed entirely client-side — can be used for injection. They can, and the platform documents enough to make it auditable.

What the exposure actually is

Lightning Message Service is a browser-side bus with no server mediation. A channel with isExposed=true is published to components in any namespace, including every installed managed package. Any component sharing a page with a publisher or subscriber can:

• subscribe and read every payload — sharing rules, OWD and FLS govern records and do not reach the bus, so the payload is readable regardless of what the reader is entitled to see;
• publish a payload of its own, feeding a subscriber attacker-controlled input.

The second is the injection you would not expect: a subscriber that takes a record id from a message and passes it to Apex, or renders it into the page, is trusting a publisher it cannot authenticate. The bus is shaped like a trust boundary and is not one.

Three facts from the docs that shape the finding

None are obvious from the setting itself, and each changes the advice:

1. Salesforce's own AppExchange Security Review requires isExposed=false. A defect by the platform owner's definition, not only ours.
2. isExposed cannot be set back to false once true. Remediation is a new channel plus migrating every publisher and subscriber — not a toggle. The remediation text says so, because implying otherwise understates the cost by a wide margin.
3. Visualforce supports only exposed channels. An org using LMS from a Visualforce page has an exposed channel because the platform requires one. "Just turn it off" would be wrong advice there, so the detail names it.

Installed channels are reported separately at LOW: identical reach, but not editable here and not reversible anyway, so there is no fix available in this org — only a question for the vendor. Reporting them together would hand a reader a remediation they cannot apply.

Verified before writing, not assumed

Queryability was the open question, and it decided the design. Confirmed against a developer edition with a read-only Tooling query:

• LightningMessageChannel is Tooling-queryable
• IsExposed is a selectable and filterable boolean (WHERE IsExposed = true executes)
• ManageableState is what separates local from installed

So no MetadataClient fallback and no advisory-degradation path — the whole check is one Tooling query.

Deliberately grants no capability

An exposed channel is a surface, not reach. Nothing in the metadata says what the channel carries, so granting data-read would assert an exposure that has not been established. Wiring it into a chain as a step is a separate judgment and is not made here.

Scope left open

The check does not cross-reference which Visualforce pages or components reference each channel, which would let it escalate severity where the exposure is load-bearing. That needs a second markup scan, and VisualforceXssCheck already pays that cost under a 500-page cap — so sharing it through the cache is the right way to add it, rather than querying ApexPage twice.

Verification

Six touches per the contract: impl class, registry entry, mapping.ts control rows plus the devSecurity DOMAIN group, CheckMeta effort/impact, unit test with a mocked Tooling client, README and docs/CHECKS.md rows with the count moved 92 → 93.

npm run build clean; npm test 1250 passing across 126 suites (from 1242). Registry confirms 93 registered checks, and the exact query string the check issues was re-run against the org after the check was written.

[cclabsnz]

Holding this as a draft. The finding text asserts that any component sharing the page can subscribe to read payloads or publish its own — that is inferred from how LMS works, not demonstrated. Establishing whether an exposed channel can actually leak data, and to whom, before this ships.