patriksimek/vm2Sandbox JavaScript isolée pour Node.js qui exécute du code non fiable avec un accès restreint aux modules intégrés et aux ressources hôte via une interception basée sur Proxy.
[![Known Vulnerabilities][snyk-image]][snyk-url]vm2 est un bac à sable qui peut exécuter du code non fiable avec les modules intégrés de Node.js figurant sur la liste blanche.
npm install vm2
## Exemples rapides```js
import { VM } from 'vm2';
const vm = new VM();
vm.run(`process.exit()`); // TypeError: process.exit is not a function
Veuillez fournir le contenu Markdown à traduire.```js import { NodeVM } from 'vm2';
const vm = new NodeVM({ require: { external: true, root: './', }, });
vm.run(
var request = require('request'); request('http://www.google.com', function (error, response, body) { console.error(error); if (!error && response.statusCode == 200) { console.log(body); // Show the HTML for the Google homepage. } });,
'vm.js',
);
## Avertissement de sécurité important
**Avant d'utiliser vm2, vous devez comprendre son fonctionnement et ses limites.**
vm2 tente de cloisonner du code JavaScript non fiable **dans le même processus Node.js** que votre application. Pour ce faire, il s'appuie sur un réseau complexe de [Proxies](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Proxy) qui interceptent et arbitrent chaque interaction entre le bac à sable et l'environnement hôte.
### Le défi fondamental
JavaScript est un langage extraordinairement dynamique. Les objets peuvent être atteints via les chaînes de prototypes, les constructeurs peuvent être atteints via les objets d'erreur, les symboles fournissent des hooks de protocole, et l'exécution asynchrone crée des fenêtres de timing. Le nombre considérable de façons de passer d'un objet à un autre en JavaScript rend la construction d'un bac à sable in-process hermétique extrêmement difficile.
**Nous sommes honnêtes à propos de cette réalité :** Malgré tous nos efforts, les chercheurs et les professionnels de la sécurité découvrent en permanence de nouvelles façons de s'échapper du bac à sable de vm2. Nous corrigeons activement ces vulnérabilités dès qu'elles sont signalées, mais la nature de jeu du chat et de la souris du cloisonnement in-process implique que :
1. **De nouvelles contournements seront probablement découverts à l'avenir.** Consultez nos [avis de sécurité](https://github.com/patriksimek/vm2/security/advisories) pour connaître les vulnérabilités connues.
2. **Vous devez maintenir vm2 à jour** pour bénéficier des derniers correctifs de sécurité. Abonnez-vous aux avis de sécurité et mettez à jour rapidement.
3. **vm2 ne doit pas être votre seule ligne de défense.** La défense en profondeur est essentielle lors de l'exécution de code non fiable.
### Alternatives plus robustes
Si vous avez besoin de garanties d'isolation plus fortes, envisagez ces alternatives qui offrent une **véritable isolation au niveau du processus ou du matériel** :
| Solution | Approche | Performance | Compromis |
|----------|----------|-------------|------------|
| **[isolated-vm](https://github.com/laverdet/isolated-vm)** | Isolats V8 séparés (tas V8 différent) | Rapide | En mode maintenance ; nécessite des mises à jour manuelles de V8 |
| **Processus séparé / Worker** | `child_process` ou threads Worker avec permissions limitées | Moyenne | Surcharge IPC plus élevée ; les données doivent être sérialisées |
| **Conteneurs / VM** | Docker, gVisor, Firecracker | Lente | Surcharge de démarrage ; gourmand en ressources |
| **Services gérés** | Exécution de code dans le cloud (par ex., AWS Lambda, Cloudflare Workers) | Variable | Latence réseau ; dépendance externe |
### Quand vm2 peut encore être approprié
vm2 peut convenir lorsque :
- Vous avez besoin d'une intégration étroite avec les objets hôtes et d'une communication synchrone rapide
- Le code non fiable provient d'une source relativement fiable (par ex., outils internes, systèmes de plugins avec des auteurs vérifiés)
- Vous combinez vm2 avec d'autres couches de sécurité (isolation réseau, restrictions du système de fichiers, limites de ressources)
- Vous acceptez le risque et surveillez activement les mises à jour de sécurité
**Si vous exécutez du code provenant de sources totalement non fiables (par ex., soumissions d'utilisateurs arbitraires), nous vous recommandons fortement d'utiliser une solution offrant des garanties d'isolation plus fortes.**
## Environnements d'exécution
| Environnement | Statut |
|---------|--------|
| Node.js | Pris en charge. Le bac à sable est une frontière de sécurité. |
| Bun | **Expérimental.** Compatibilité fonctionnelle partielle — **pas** une frontière de sécurité. |
Deux limitations distinctes s'appliquent à Bun, et aucune n'implique l'autre.
**Ce n'est pas une frontière de sécurité.** Le modèle de menace de vm2, le catalogue d'attaques dans
[`docs/ATTACKS.md`](https://github.com/patriksimek/vm2/blob/main/docs/ATTACKS.md), et chaque test de régression dans `test/ghsa/`
sont dérivés des mécanismes internes de V8. JavaScriptCore, que Bun utilise, a ses propres
équivalents, et aucun n'a été audité par rapport au pont de vm2. La suite qui passe
sous Bun démontre une compatibilité, pas que le bac à sable tient là-bas. **N'utilisez pas
vm2 sur Bun pour isoler du code non fiable.**
**La compatibilité est partielle, pas une parité.** Un passage vert sous Bun ne couvre que les tests
qui s'y exécutent réellement. `test/bun-skips.js` liste ce qui est exclu et pourquoi,
et les écarts de comportement connus incluent :
- `Buffer.from(arrayLike)` renvoie un buffer de longueur nulle
- Les métadonnées `filename` / `lineOffset` / `columnOffset` de `VMScript` ne sont pas
observables, car les objets CallSite de JSC ne portent aucune méthode
- `Object.freeze` sur un objet hôte gelé avec un accesseur non configurable
lève une `TypeError` d'invariant de proxy là où V8 ne le fait pas
- certaines opérations `Buffer` à travers la frontière du bac à sable sont considérablement plus lentes —
un `allocUnsafe` de 64 Mo prend plus de 400 secondes contre 1,7 sur Node, assez lent
pour être perçu comme un blocage
Considérez la prise en charge de Bun comme une compatibilité au mieux pour du code fiable, et vérifiez la
liste des exclusions avant de vous fier à un comportement particulier.
## Fonctionnalités
- Exécute du code non fiable en toute sécurité dans un seul processus, en parallèle de votre code
- Contrôle total de la sortie console du bac à sable
- Le bac à sable a un accès limité aux méthodes du processus
- Il est possible de requérir des modules (intégrés et externes) depuis le bac à sable
- Vous pouvez limiter l'accès à certains (ou tous) modules intégrés
- Vous pouvez appeler des méthodes en toute sécurité et échanger des données et des callbacks entre les bacs à sable
- Maintenu activement avec des correctifs pour les méthodes d'évasion connues (voir [Avertissement de sécurité](#important-security-disclaimer))
- Prise en charge du transpileur
## Comment cela fonctionne
- Il utilise le module VM interne pour créer un contexte sécurisé.
- Il utilise des [Proxies](https://developer.mozilla.org/docs/Web/JavaScript/Reference/Global_Objects/Proxy) pour empêcher l'évasion du bac à sable.
- Il remplace le require intégré pour contrôler l'accès aux modules.
Pour un aperçu approfondi des mécanismes internes de vm2, voir [docs/ATTACKS.md](https://github.com/patriksimek/vm2/blob/main/docs/ATTACKS.md).
## Quelle est la différence entre le module vm de Node et vm2 ?
Essayez par vous-même :```js
import { runInNewContext } from "node:vm";
runInNewContext('this.constructor.constructor("return process")().exit()');
console.log('Never gets executed.');
## 🛡️ Fonctionnalités de sécurité