SOLFIND
Web Lens
Portal home

Context Isolation | Electron

https://www.electronjs.org/docs/latest/tutorial/context-isolation • 49 KB fetched
Open original page


Context Isolation | Electron Skip to main content Electron Docs API Blog Tools * Electron Forge * Electron Fiddle Community * Governance * Showcase * Resources Releases English * English * Deutsch * Español * Français * 日本語 * Português * Русский * 中文 Search * Get Started * Processes in Electron * Process Model * Context Isolation * Inter-Process Communication * Process Sandboxing * MessagePorts in Electron * Best Practices * Examples * Development * Native Node Modules * Distribution * Testing And Debugging * References * Contributing * * Processes in Electron * Context Isolation On this page Context Isolation What is it? ​ Context Isolation is a feature that ensures that both your preload scripts and Electron's internal logic run in a separate context to the website you load in a webContents . This is important for security purposes as it helps prevent the website from accessing Electron internals or the powerful APIs your preload script has access to. This means that the window object that your preload script has access to is actually a different object than the website would have access to. For example, if you set window.hello = 'wave' in your preload script and context isolation is enabled, window.hello will be undefined if the website tries to access it. Context isolation has been enabled by default since Electron 12, and it is a recommended security setting for all applications . Migration ​ Without context isolation, I used to provide APIs from my preload script using window.X = apiObject . Now what? Before: context isolation disabled ​ Exposing APIs from your preload script to a loaded website in the renderer process is a common use-case. With context isolation disabled, your preload script would share a common global window object with the renderer. You could then attach arbitrary properties to a preload script: preload.js // preload with contextIsolation disabled window . myAPI = { doAThing : ( ) => { } } The doAThing() function could then be used directly in the renderer process: renderer.js // use the exposed API in the renderer window . myAPI . doAThing ( ) After: context isolation enabled ​ There is a dedicated module in Electron to help you do this in a painless way. The contextBridge module can be used to safely expose APIs from your preload script's isolated context to the context the website is running in. The API will also be accessible from the website on window.myAPI just like it was before. preload.js // preload with contextIsolation enabled const { contextBridge } = require ( 'electron' ) contextBridge . exposeInMainWorld ( 'myAPI' , { doAThing : ( ) => { } } ) renderer.js // use the exposed API in the renderer window . myAPI . doAThing ( ) Please read the contextBridge documentation linked above to fully understand its limitations. For instance, you can't send custom prototypes or symbols over the bridge. Security considerations ​ Just enabling contextIsolation and using contextBridge does not automatically mean that everything you do is safe. For instance, this code is unsafe . preload.js // ❌ Bad code contextBridge . exposeInMainWorld ( 'myAPI' , { send : ipcRenderer . send } ) It directly exposes a powerful API without any kind of argument filtering. This would allow any website to send arbitrary IPC messages, which you do not want to be possible. The correct way to expose IPC-based APIs would instead be to provide one method per IPC message. preload.js // ✅ Good code contextBridge . exposeInMainWorld ( 'myAPI' , { loadPreferences : ( ) => ipcRenderer . invoke ( 'load-prefs' ) } ) Usage with TypeScript ​ If you're building your Electron app with TypeScript, you'll want to add types to your APIs exposed over the context bridge. The renderer's window object won't have the correct typings unless you extend the types with a declaration file . For example, given this preload.ts script: preload.ts contextBridge . exposeInMainWorld ( 'electronAPI' , { loadPreferences : ( ) => ipcRenderer . invoke ( 'load-prefs' ) } ) You can create a interface.d.ts declaration file and globally augment the Window interface: interface.d.ts export interface IElectronAPI { loadPreferences : ( ) => Promise < void > , } declare global { interface Window { electronAPI : IElectronAPI } } Doing so will ensure that the TypeScript compiler will know about the electronAPI property on your global window object when writing scripts in your renderer process: renderer.ts window . electronAPI . loadPreferences ( ) Edit this page Previous Process Model Next Inter-Process Communication * What is it? * Migration * Before: context isolation disabled * After: context isolation enabled * Security considerations * Usage with TypeScript Docs * Getting Started * API Reference Checklists * Performance * Security Tools * Electron Forge * Electron Fiddle Community * Governance * Resources * Bluesky * X * Mastodon * Stack Overflow More * GitHub * Open Collective * Infrastructure Dashboard Copyright OpenJS Foundation and Electron contributors. All rights reserved. The OpenJS Foundation has registered trademarks and uses trademarks. For a list of trademarks of the OpenJS Foundation , please see our Trademark Policy and Trademark List . Trademarks and logos not indicated on the list of OpenJS Foundation trademarks are trademarks™ or registered® trademarks of their respective holders. Use of them does not imply any affiliation with or endorsement by them. The OpenJS Foundation | Terms of Use | Privacy Policy | Bylaws | Code of Conduct | Trademark Policy | Trademark List | Cookie Policy Hosting and infrastructure graciously provided by

Links found on this page

  1. Skip to main content [direct]
  2. Electron [direct]
  3. Docs [direct]
  4. API [direct]
  5. Blog [direct]
  6. Electron Forge [direct]
  7. Electron Fiddle [direct]
  8. Governance [direct]
  9. Showcase [direct]
  10. Resources [direct]
  11. Releases [direct]
  12. Deutsch [direct]
  13. Español [direct]
  14. Français [direct]
  15. 日本語 [direct]
  16. Português [direct]
  17. Русский [direct]
  18. 中文 [direct]
  19. Processes in Electron [direct]
  20. Inter-Process Communication [direct]
  21. Process Sandboxing [direct]
  22. MessagePorts in Electron [direct]
  23. Best Practices [direct]
  24. Examples [direct]
  25. Development [direct]
  26. Native Node Modules [direct]
  27. Distribution [direct]
  28. Testing And Debugging [direct]
  29. References [direct]
  30. Contributing [direct]
  31. webContents [direct]
  32. contextBridge [direct]
  33. declaration file [direct]
  34. Edit this page [direct]
  35. Security [direct]
  36. Bluesky [direct]
  37. X [direct]
  38. Mastodon [direct]
  39. Stack Overflow [direct]
  40. GitHub [direct]
  41. Open Collective [direct]
  42. Infrastructure Dashboard [direct]
  43. OpenJS Foundation [direct]
  44. Trademark Policy [direct]
  45. Trademark List [direct]
  46. Terms of Use [direct]
  47. Privacy Policy [direct]
  48. Bylaws [direct]
  49. Code of Conduct [direct]
  50. Cookie Policy [direct]