Mise en bac à sable du processus de rendu
Activez et configurez la mise en bac à sable de vos processus de rendu afin de limiter leur accès aux ressources système et de renforcer la sécurité de votre application.
Mise en bac à sable du processus de rendu est une leçon Electron Desktop App Development gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Electron Desktop App Development, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Electron Desktop App Development comprend 4 leçons au total.
Certaines parties de cette leçon n'ont pas encore été traduites et s'affichent en anglais.
What is Sandboxing?
Imagine your computer as a house. Some guests (apps) you trust completely, others you want to keep in a specific room with limited access.
Sandboxing is like putting your app's renderer process in a secure, isolated "room." It limits what that part of your app can do and access on your system.
This is crucial for security, especially when displaying untrusted web content or protecting against malicious scripts.
Why Sandboxing Matters
Electron apps combine web content (HTML, CSS, JS) with native desktop capabilities. Without proper isolation, a vulnerability in your web content could be exploited to access your user's file system or other system resources.
Sandboxing prevents this by isolating the renderer process, making it much harder for malicious code to "break out" and harm the user's system.
Chromium's Security Layer
Electron uses Chromium, the same engine that powers Google Chrome. A key security feature of Chromium is its renderer sandbox.
By default in browsers, web pages run in a sandboxed renderer process, meaning they can't directly interact with your operating system. Electron extends this robust security model to your desktop applications.
Activating the Sandbox
Enabling sandboxing in Electron is straightforward. You do it when creating a new BrowserWindow by setting the sandbox option to true in webPreferences.
This is a critical step for enhancing the security posture of your Electron application.
const { app, BrowserWindow } = require('electron');
function createWindow () {
const win = new BrowserWindow({
width: 800,
height: 600,
webPreferences: {
sandbox: true // Set to true to enable sandboxing
}
});
win.loadFile('index.html'); // Loads your web content
}
app.whenReady().then(createWindow);
app.on('window-all-closed', () => {
if (process.platform !== 'darwin') app.quit();
});Renderer Process Limitations
When a renderer process is sandboxed, it faces significant restrictions:
- It cannot directly access Node.js APIs (e.g.,
require,process,fs). - It cannot use native modules.
- Its access to system resources (like files) is severely limited.
This isolation prevents web content from performing unauthorized actions on the user's computer.
Node.js Access Denied Demo
Let's see what happens when a sandboxed renderer tries to access Node.js directly. The code below creates a window with sandboxing enabled and attempts to use the fs module.
Run this example and check the developer console (usually F12 or Cmd+Option+I) for the error message.
const { app, BrowserWindow } = require('electron');
function createWindow () {
const win = new BrowserWindow({
width: 600,
height: 400,
webPreferences: {
sandbox: true, // Sandboxing enabled
nodeIntegration: false, // Explicitly disabled (default with sandbox)
contextIsolation: true // Explicitly enabled (default with sandbox)
}
});
// Load HTML that tries to use Node.js 'fs' module
win.loadURL(`data:text/html;charset=utf-8,
<!DOCTYPE html>
<html>
<head>
<title>Sandboxed Demo</title>
</head>
<body>
<h1>Sandboxed Renderer Test</h1>
<p id="message">Attempting to access Node.js...</p>
<script>
try {
const fs = require('fs'); // This will fail!
document.getElementById('message').innerText = 'Node.js fs module loaded!';
} catch (error) {
document.getElementById('message').innerText = 'Error: ' + error.message;
console.error('Renderer error:', error);
}
</script>
</body>
</html>
`);
win.webContents.openDevTools(); // Open DevTools to see the error
}
app.whenReady().then(createWindow);
app.on('window-all-closed', () => {
if (process.platform !== 'darwin') app.quit();
});Secure Interaction: Preload
Since sandboxed renderers can't directly access Node.js, how do they perform system tasks?
You use preload scripts with context isolation. These scripts run before your web content, have Node.js access, and can securely expose a limited API to your sandboxed renderer via contextBridge.
This ensures that your main process controls exactly what functionality is exposed.
Sandbox & Context Isolation
It's important to note that when webPreferences.sandbox is true, both nodeIntegration will be false and contextIsolation will be true by default, regardless of what you explicitly set.
This combination provides the strongest security for your renderer processes.
Best Practices
- Always enable sandboxing: It's a fundamental security measure.
- Minimize exposed APIs: Only expose essential functionality via preload scripts.
- Validate all inputs: Any data passed from a renderer to the main process should be validated.
These practices create a robust and secure Electron application.
Quick Check
Understanding sandboxing is key to building secure Electron applications.
Recap: Securing Your App
In this lesson, we explored sandboxing in Electron. We learned that it's a critical security feature that isolates your renderer processes, preventing them from directly accessing system resources or Node.js APIs.
By setting webPreferences.sandbox: true, you activate this powerful protection, ensuring a safer application. Remember to use preload scripts with context isolation for secure communication between your sandboxed renderer and the main process.
Questions Fréquemment Posées
La leçon « Mise en bac à sable du processus de rendu » est-elle gratuite ?
Oui — le texte complet de « Mise en bac à sable du processus de rendu » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Electron Desktop App Development, passe à CoddyKit PRO. Le cours Electron Desktop App Development comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Mise en bac à sable du processus de rendu » ?
Activez et configurez la mise en bac à sable de vos processus de rendu afin de limiter leur accès aux ressources système et de renforcer la sécurité de votre application. Tu pratiques Electron Desktop App Development avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Electron Desktop App Development ?
Aucune expérience préalable n'est requise. Electron Desktop App Development sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.
Combien de temps prend la leçon « Mise en bac à sable du processus de rendu » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Electron Desktop App Development ?
Oui. Chaque leçon Electron Desktop App Development inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Modèles IPC sécurisés
- Isolation des contextes et scripts de préchargement
- Mise en bac à sable du processus de rendu
- Renforcer la protection contre les risques liés au contenu distant