feat: add webFrame.securityOrigin

[samuelmaddock]

Description of Change

Adds securityOrigin property to renderer's webFrame module.

Security origin tells a WebFrame which scripting context group it belongs to. A collection of same-site frames created using <iframe>, open(sameSiteUrl), or open('about:blank') will have the same security origin.

A use case for this feature is to determine whether a preload script in an about:blank popup should run if its security origin is the same as the secure host WebContents.

cc @MarshallOfSound @nornagon

Checklist

• PR description included and stakeholders cc'd
• npm test passes
• tests are changed or added
• relevant documentation is changed or added
• PR release notes describe the change in a way relevant to app developers, and are capitalized, punctuated, and past tense.

Release Notes

Notes: Added webFrame.securityOrigin to determine the security origin of the frame.

[nornagon]

This seems kind of minimally useful on the renderer side, as it's not really trustable. Does GetLastCommittedOrigin on the browser side fulfill a similar purpose? https://source.chromium.org/chromium/chromium/src/+/main:content/public/browser/render_frame_host.h;l=518;drc=fa230cce5395b280afd13ae362eabd0a680fc72a

[samuelmaddock]

This seems kind of minimally useful on the renderer side, as it's not really trustable. Does GetLastCommittedOrigin on the browser side fulfill a similar purpose? https://source.chromium.org/chromium/chromium/src/+/main:content/public/browser/render_frame_host.h;l=518;drc=fa230cce5395b280afd13ae362eabd0a680fc72a

The use case for this feature is intended primarily for preload scripts to gate any code intended for specific sites.

// preload.js
const { webFrame } = require('electron');

if (webFrame.securityOrigin === 'https://example.app.domain/') {
  // Run my app-specific code
}

In the future, it'd be better if we could restrict preload scripts from running at all on certain origins. Much more work would be necessary for that change though.

More research is needed for determining browser-side validation of IPC which will come in a future PR.

[nornagon]

Hm, I don't think that's really a super secure way to limit stuff in preload. It's better than what we have now, but it's not watertight as the renderer can theoretically be compromised. This really needs to be done browser-side by limiting preloads on a per-process / per-SiteInstance basis.

I'm 👎 on this API since it seems like the only uses would be incorrect-ish ones.

[nornagon]

is this superseded by #35438?

[samuelmaddock]

is this superseded by #35438?

I think we still need a way to be able to guard preload code from running in certain contexts.

Preload scripts are currently run in all renderer contexts (main world by default). If we'd like to run preload code only in certain contexts—like those matching a certain security origin—we can only do so by guarding code within the preload itself.

example:

if (location.origin === 'https://electronjs.org') {
  // run the code specific for this origin
}

Probably better would be to have some filtering at the point a preload script is registered, but that will require more significant refactoring.

[nornagon]

Yeah... I'm not sure I feel this is a good way to guard preload code. Your example used location.origin, is that already good enough to do this sort of guarding, at least somewhat? If we're going to introduce a new API intended to be used to selectively run preload code, I don't think this is it.

[nornagon]

Throwing API DECLINED for the bot

[samuelmaddock]

Closing since we no longer have an immediate need for this. Ultimately we should try to solve this with filtering from the main process if needed later.