JS-2205 USER-2389 Support Window onmessage in S2819

[francois-mora-sonarsource]

Part of USER-2389

What changed

S2819 now detects unverified Window.onmessage registrations alongside the existing addEventListener("message", ...) support.

Covered receivers are non-computed onmessage assignments on window and globalThis, including local aliases whose unique write resolves to one of them (const target = window). The receiver's onmessage property must be declared in lib.dom.d.ts, which leaves Worker and Node projects alone since they compile against lib.webworker.d.ts or no DOM lib at all.

Files that alias the global with a window = self / window = global shim are excluded: they run in a Worker, where messages come from the parent and there is no origin to verify. Types cannot tell this apart, since self and window are both Window & typeof globalThis once the DOM lib is loaded, so the shim is detected syntactically. ace/lib/ace/worker/worker_v2.js in the ruling sources is exactly this case.

Listener resolution is shared with the addEventListener path, which as a side effect also resolves handlers held in const variables (const handler = event => {...}) — previously only function declarations were followed, so addEventListener gains a few true positives too.

Out of scope

• Computed and dynamic properties (window["onmessage"]).
• Compound assignments (??=, ||=), which do register a handler and are a known false negative.
• Window-typed values that do not resolve to window/globalThis: parameters, iframe.contentWindow, document.defaultView.
• Non-Window transports such as WebSocket, MessagePort or BroadcastChannel.
• The same Worker shim on the addEventListener path, which reports it today. Harmonising the two paths would remove issues from the ruling baseline and belongs in its own change.

Why

Assignments to Window.onmessage receive postMessage events and require the same origin verification as addEventListener("message", ...).

Validation

• npx tsx --tsconfig packages/tsconfig.test.json --test packages/analysis/src/jsts/rules/S2819/unit.test.ts
• npx tsc --noEmit -p packages/tsconfig.test.json
• npm run bbf
• git diff --check origin/master...HEAD
• Ruling: expected results unchanged.

[hashicorp-vault-sonar-prod]

JS-2205

[github-actions]

Ruling Report

No changes to ruling expected issues in this PR

[francois-mora-sonarsource]

Two known gaps, left deliberately out of this PR and recorded here rather than as tickets:

1. Compound assignments are not detected. window.onmessage ??= handler and window.onmessage ||= handler do register a handler, so they are false negatives. The guard is a single condition (assignment.operator !== '='), but widening it can add issues to the ruling baseline, so it is worth doing as its own change.

2. The addEventListener path still reports Worker shims. A file doing window = self and then window.addEventListener("message", handler) is reported, whereas the same file assigning window.onmessage is now excluded. isWindowObject accepts any identifier whose name matches /window/i, so it also reports non-Window receivers such as const workerWindow = new WebSocket(...). Routing both paths through isWindowMessageReceiver would harmonise them and remove those false positives, which means updating the ruling expected results — again its own change.

For context on why the shim exclusion exists at all: dropping it made ruling fail with exactly one new issue, ace/lib/ace/worker/worker_v2.js:71, which aliases window = self at the top of a module factory and then registers window.onmessage. Messages there come from the parent page and event.origin is "", so there is nothing to verify. Types cannot separate the two cases, since self and window are both Window & typeof globalThis once the DOM lib is loaded.

[gitar-bot]

Code Review ✅ Approved 2 resolved / 2 findings

Adds S2819 support for unverified Window.onmessage registrations while refining receiver validation and alias resolution, addressing the non-Window false positives and alias suppression findings.

✅ 2 resolved

✅ Edge Case: onmessage check may false-positive on non-Window objects

📄 packages/analysis/src/jsts/rules/S2819/rule.ts:66-70 📄 packages/analysis/src/jsts/rules/S2819/rule.ts:111-125 📄 packages/analysis/src/jsts/rules/S2819/rule.ts:403-417
isWindowObject treats any object whose reference/identifier name contains the substring "window" (via WindowNameVisitor, regex /window/i) as a Window. Applying this heuristic to the new onmessage assignment surface broadens false-positive risk, because onmessage is a common property on non-Window objects (WebSocket, Worker, EventSource, MessagePort). E.g. const eventWindowChannel = new WebSocket(...); eventWindowChannel.onmessage = fn; would be flagged even though it is not a Window. Consider requiring the type-string match for aliases here, or restricting the name heuristic to exact window/globalThis identifiers rather than substring matches.

✅ Edge Case: window=self alias suppresses S2819 for entire file

📄 packages/analysis/src/jsts/rules/S2819/rule.ts:136 📄 packages/analysis/src/jsts/rules/S2819/rule.ts:157-167
isWindowAliasedToWorkerGlobal scans every scope in the file and returns true if any window = self/window = global write exists anywhere. Because isWindowMessageReceiver short-circuits on this, a single worker-polyfill assignment disables origin checking for all window.onmessage handlers in the file, potentially masking genuinely unverified handlers (false negative). Consider scoping the alias check to the receiver/scope of the specific assignment being analyzed rather than the whole file.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
94.2% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube