fix(service-worker): verify event source before processing INITIALIZE message#68898
Draft
arturovt wants to merge 1 commit into
Draft
fix(service-worker): verify event source before processing INITIALIZE message#68898arturovt wants to merge 1 commit into
arturovt wants to merge 1 commit into
Conversation
… message Previously, the `INITIALIZE` action in `onMessage` was handled before the `isClient()` guard, allowing any source — including cross-origin iframes or unknown `MessagePort` handles — to trigger SW initialization without verification. The fix explicitly checks that the message source is either the SW's own registration or a legitimate client before proceeding with `ensureInitialized`. **Example of the previous behavior:** A cross-origin iframe with a `postMessage` handle to the SW could trigger initialization at an arbitrary time: ```js // attacker-controlled iframe on https://evil.com navigator.serviceWorker.getRegistration('/').then(reg => { reg.active.postMessage({ action: 'INITIALIZE' }); }); ``` This would bypass the `isClient()` check that guards all other actions and invoke `ensureInitialized()` from an untrusted source, racing with cache writes during first-load initialization. **After the fix**, messages with `action: 'INITIALIZE'` are accepted only from the SW's own registration (`self.registration.active/installing/waiting`) or from a verified client. All other sources are silently dropped, consistent with how all other actions are handled.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously, the
INITIALIZEaction inonMessagewas handled before theisClient()guard, allowing any source — including cross-origin iframes or unknownMessagePorthandles — to trigger SW initialization without verification.The fix explicitly checks that the message source is either the SW's own registration or a legitimate client before proceeding with
ensureInitialized.Example of the previous behavior:
A cross-origin iframe with a
postMessagehandle to the SW could trigger initialization at an arbitrary time:This would bypass the
isClient()check that guards all other actions and invokeensureInitialized()from an untrusted source, racing with cache writes during first-load initialization.After the fix, messages with
action: 'INITIALIZE'are accepted only from the SW's own registration (self.registration.active/installing/waiting) or from a verified client. All other sources are silently dropped, consistent with how all other actions are handled.