Lack of ContextIsolation & Insecure Preload

You should also avoid exposing any IPC objects directly to the DOM from the preload script, though without ContextIsolation it’s trivial to escape the sandbox using prototype pollution attacks.

There’s a couple different ways to approach this, my solution is detailed here but certainly isn’t the only way to address the problem.

[MarshallOfSound]

@reZach That commit just blanket exposes all of ipcRenderer, as I outlined in my comment you linked above the safe thing to do here is expose the minimal required API surface. In it’s current state anything in the main context can send / listen for any ipc message.

[reZach]

Thanks @moloch-- and @MarshallOfSound. If you are interested, I’ve updated my i18next-electron-fs-backend repo with the following commit that I think adequately limits the channels the ipcRenderer/ipcMain can communicate on.

This change accomplishes a few things I was looking for:

1. Keeping the channel keys in the package itself.
2. Only allows the channel keys defined in the package for communication between the main and renderer processes.
3. Allows the user to write nice bindings in the preload.js and main.js scripts to hook everything up.

I was considering a nonce or secret key or some other form of anti-tampering but I couldn’t/didn’t want to do that tonight so we (I) can table it unless the community feels its pressing to add. If you have more concerns I can re-open this issue.

Thanks both for your feedback!