अपने बैकएंड पर Node.js या Python में यूज़र का अविश्वसनीय कोड चलाने का सबसे सुरक्षित तरीका क्या है?

यूज़र के अविश्वसनीय कोड को अपने वेब बैकएंड से बाहर ऐसे एक्ज़ीक्यूशन एनवायरनमेंट में चलाएँ जिसे काम के बाद हटा सकें। किसी भी तरह का Node.js या Python कोड स्वीकार करने वाली सार्वजनिक सर्विस के लिए, हर जॉब या टेनेंट सेशन को सही तरह से कॉन्फ़िगर किया हुआ microVM देना एक मज़बूत डिफ़ॉल्ट विकल्प है। प्रोडक्शन क्रेडेंशियल बाहर रखें, गैरज़रूरी नेटवर्क एक्सेस ब्लॉक करें, और वर्कलोड के बाहर से रिसोर्स लिमिट और एक्सपायरी लागू करें।

यूज़र का ऑथेंटिकेशन करने, जॉब कतार में लगाने और नतीजे लौटाने के लिए अपना Express, FastAPI या Django ऐप इस्तेमाल करें। एक अलग वर्कर को एक्ज़ीक्यूशन संभालने दें। सिर्फ़ प्रोग्रामिंग भाषा के स्तर की पाबंदियां इस डिज़ाइन के लिए ज़रूरी आइसोलेशन नहीं देतीं।

सही सेटअप इस पर निर्भर करता है कि यूज़र क्या सबमिट कर सकते हैं। कैलकुलेटर एक छोटी एक्सप्रेशन भाषा स्वीकार कर सकता है। पैकेज इंस्टॉल करने और शेल कमांड चलाने वाले कोडिंग एजेंट को पूरा एक्ज़ीक्यूशन एनवायरनमेंट चाहिए। हम इस दूसरे मामले पर ध्यान देते हैं, जिसमें यूज़र इनपुट से AI का बनाया कोड भी शामिल है।

पहले आइसोलेशन की सीमा चुनें

Docker की सुरक्षा होस्ट, डेमन और कॉन्फ़िगरेशन पर निर्भर करती है। gVisor यूज़रस्पेस एप्लिकेशन कर्नेल जोड़ता है। Firecracker microVM चलाने के लिए KVM इस्तेमाल करता है। इनमें से कोई भी विकल्प यह तय नहीं करता कि आपके ऐप को कौन-से क्रेडेंशियल या नेटवर्क डेस्टिनेशन उपलब्ध कराने चाहिए। Docker सुरक्षा, gVisor आर्किटेक्चर, Firecracker।

ज़्यादा सख़्त ज़रूरतों के लिए समर्पित वर्कर होस्ट या अकाउंट पर भी विचार करें। VM की सीमा साझा कर्नेल से जुड़ा जोखिम घटाती है; इससे यह साबित नहीं होता कि बाहर निकलने का हर संभव तरीका या हार्डवेयर साइड चैनल असंभव है।

Node.js और Python को बाहरी सैंडबॉक्स क्यों चाहिए

Node.js: VM कॉन्टेक्स्ट सुरक्षा सीमा नहीं है

Node का अपना डॉक्यूमेंटेशन कहता है कि अविश्वसनीय कोड के लिए node:vm को सुरक्षा उपाय के रूप में इस्तेमाल नहीं करना चाहिए। vm.runInNewContext को खाली ऑब्जेक्ट या टाइमआउट देने से यह बात नहीं बदलती। Node.js VM डॉक्यूमेंटेशन।

वर्कर थ्रेड एक साथ काम चलाने में मदद करते हैं। चाइल्ड प्रोसेस वेब सर्वर को इंटरप्रेटर के सामान्य क्रैश से बचा सकता है। इनमें से कोई भी अपने आप फ़ाइलसिस्टम एक्सेस, विरासत में मिले एनवायरनमेंट वेरिएबल या नेटवर्क एक्सेस नहीं हटाता। आपके सर्वर की OS परमिशन के साथ चलने वाला चाइल्ड प्रोसेस उन रिसोर्स तक पहुंच सकता है जिनकी ये परमिशन अनुमति देती हैं।

Node का Permission Model भी कहता है कि वह नुकसान पहुंचाने वाले कोड के ख़िलाफ़ सुरक्षा की गारंटी नहीं देता। जहां उपयोगी हो, इसे अतिरिक्त पाबंदी के तौर पर इस्तेमाल करें और नुकसान पहुंचाने वाले सबमिशन के लिए बाहरी सीमा रखें। Node.js परमिशन।

Python: नामों पर पाबंदी लगाने से प्रोसेस सीमित नहीं होता

Python चेतावनी देता है कि exec और eval किसी भी तरह का कोड चलाते हैं। __builtins__ हटाने या कुछ इम्पोर्ट ब्लॉक करने से बिना पाबंदी वाला Python सुरक्षित एक्ज़ीक्यूशन सर्विस नहीं बन जाता। RestrictedPython भी भाषा के एक सीमित हिस्से का वर्णन करता है और खुद अपने दम पर सैंडबॉक्स देने का दावा नहीं करता। Python बिल्ट-इन फ़ंक्शन, RestrictedPython।

डेटा के लिए सीमित आकार का JSON डॉक्यूमेंट स्वीकार करें और उसका ढांचा जांचें। ast.literal_eval किसी भी तरह का Python कोड नहीं चलाता, लेकिन Python के डॉक्यूमेंटेशन में नुकसान पहुंचाने वाले इनपुट से मेमोरी, CPU और स्टैक खत्म होने के जोखिम दर्ज हैं। यह सामान्य प्रोग्राम भी सपोर्ट नहीं करता। Python AST डॉक्यूमेंटेशन।

पूरे Python के लिए चुने गए सैंडबॉक्स के अंदर अलग इंटरप्रेटर शुरू करें। वेब रिक्वेस्ट पार्सिंग और यूज़र ऑथेंटिकेशन को उससे बाहर रखें।

अविश्वसनीय कोड चलाने के लिए बैकएंड आर्किटेक्चर

जॉब रिकॉर्ड और एक्सेस नियम बैकएंड के नियंत्रण में होने चाहिए:

1. कॉल करने वाले का ऑथेंटिकेशन करें और उसका कोटा जांचें। सोर्स को बफ़र करने से पहले रिक्वेस्ट के बाइट सीमित करें।
2. सोर्स को डेटा के रूप में स्टोर करें। जॉब को किसी टेनेंट से जोड़ें और तय अलाउलिस्ट से रनटाइम चुनें।
3. जॉब को कतार में लगाएँ। भरोसेमंद वर्कर तय लिमिट और एक्सपायरी के साथ नया सैंडबॉक्स बनाता है।
4. सिर्फ़ जॉब का इनपुट ट्रांसफ़र करें। सोर्स को फ़ाइल या stdin से पास करते हुए तय इंटरप्रेटर कमांड चलाएँ।
5. सीमित आउटपुट और स्टेटस इकट्ठा करें। नतीजे लौटाने या किसी दूसरी सर्विस में इस्तेमाल करने से पहले उन्हें जांचें।
6. एक्ज़ीक्यूशन एनवायरनमेंट को रोकें और हटाएँ। अलग क्लीनअप वर्कर छूटे हुए जॉब संभालता है।

सैंडबॉक्स प्रोवाइडर की कुंजी, Docker सॉकेट और क्लाउड कंट्रोल क्रेडेंशियल भरोसेमंद वर्कर में रखें। यूज़र कोड को वे क्रेडेंशियल नहीं मिलने चाहिए जिनसे दूसरे सैंडबॉक्स बनते या मैनेज होते हैं।

हर ऑपरेशन में टेनेंट का स्वामित्व जांचें: चलाना, रद्द करना, डाउनलोड करना, फिर शुरू करना और हटाना। क्लाइंट से मिला सैंडबॉक्स ID सिर्फ़ पहचान है, एक्सेस का सबूत नहीं। पूरे एक्ज़ीक्यूशन फ़्लो के लिए हमारी AI सैंडबॉक्स गाइड देखें।

पहला यूज़र जॉब चलाने से पहले सेट करने वाले कंट्रोल

CPU का आवंटन तय करता है कि बिज़ी लूप कितनी तेज़ चलेगा। बीते समय की सीमा तय करती है कि वह कितनी देर तक चलेगा। दोनों लागू करें। Docker के डॉक्यूमेंटेशन के अनुसार, जब तक आप कॉन्फ़िगर न करें, कंटेनर पर CPU या मेमोरी की कोई पाबंदी नहीं होती। Docker रिसोर्स लिमिट।

नेटवर्क पॉलिसी में सार्वजनिक इंटरनेट के साथ प्राइवेट सर्विस और क्लाउड मेटाडेटा भी शामिल होने चाहिए। अगर जॉब को HTTP चाहिए, तो आउटबाउंड प्रॉक्सी या नेटवर्क लेयर पर ऐसी अलाउलिस्ट लागू करें जिसे गेस्ट बदल न सके। DNS रिज़ॉल्यूशन, IPv4/IPv6 डेस्टिनेशन और रीडायरेक्ट जांचें। गेस्ट के अंदर fetch का रैपर हर उस प्रोग्राम को कंट्रोल नहीं कर सकता जिसे गेस्ट चला सकता है। OWASP SSRF रोकथाम।

Node.js और Python के लिए टेस्ट किए गए Docker लॉन्च उदाहरण

ये कमांड तय सैंपल प्रोग्राम के साथ कंटेनर लॉन्च कंट्रोल दिखाती हैं। इनमें सार्वजनिक सबमिशन के लिए ज़रूरी बाहरी समय-सीमा और आउटपुट सुपरवाइज़र शामिल नहीं है। इन्हें अपने ऐप सर्वर से अलग एक्ज़ीक्यूशन वर्कर पर चलाएँ। नुकसान पहुंचाने वाले कोड को स्वीकार करने वाली सार्वजनिक सर्विस के लिए उस वर्कर को चुनी गई VM सीमा के अंदर रखें या सही सैंडबॉक्स रनटाइम इस्तेमाल करें।

भरोसेमंद, पैच की हुई इमेज इस्तेमाल करें। नीचे के टैग उदाहरण के लिए सुविधाजनक हैं; डिप्लॉयमेंट में जांची हुई इमेज का डाइजेस्ट पिन करें और अपनी सामान्य पैच प्रक्रिया से उसे अपडेट करें। जॉब स्वीकार करने से पहले इमेज पुल कर लें।

Node.js का उदाहरण

docker run --rm -i --init \
  --network none --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,nodev,size=16m \
  --user 65534:65534 --cap-drop ALL \
  --security-opt no-new-privileges \
  --memory 128m --memory-swap 128m --cpus 0.5 \
  --pids-limit 32 --ulimit nofile=64:64 \
  --log-driver none \
  node:24-bookworm-slim node - <<'JS'
console.log(JSON.stringify({answer: 6 * 7}));
JS

अपेक्षित आउटपुट {"answer":42} है। कमांड UID 65534 के रूप में चलती है, Linux capabilities हटाती है, रूट फ़ाइलसिस्टम को रीड-ओनली रखती है और छोटा, लिखने योग्य /tmp देती है। यह कोई बाहरी नेटवर्क इंटरफ़ेस नहीं देती और होस्ट की कोई डायरेक्टरी माउंट नहीं करती।

Python का उदाहरण

docker run --rm -i --init \
  --network none --read-only \
  --tmpfs /tmp:rw,noexec,nosuid,nodev,size=16m \
  --user 65534:65534 --cap-drop ALL \
  --security-opt no-new-privileges \
  --memory 128m --memory-swap 128m --cpus 0.5 \
  --pids-limit 32 --ulimit nofile=64:64 \
  --log-driver none \
  python:3.13-slim-bookworm python -I -B -u - <<'PYCODE'
import json
print(json.dumps({"answer": 6 * 7}))
PYCODE

अपेक्षित आउटपुट {"answer": 42} है। Python का -I इम्पोर्ट पाथ और इंटरप्रेटर एनवायरनमेंट का दखल घटाता है। यह प्रोग्राम को उन OS रिसोर्स का इस्तेमाल करने से नहीं रोकता जिनकी कंटेनर अनुमति देता है। Python कमांड-लाइन विकल्प।

Docker की डिफ़ॉल्ट seccomp प्रोफ़ाइल रखें। no-new-privileges, setuid एक्ज़ीक्यूटेबल जैसे तरीकों से अधिक अधिकार पाने को ब्लॉक करता है। --network none मोड सिर्फ़ लूपबैक छोड़ता है। इन कंट्रोल के काम अलग हैं; कोई भी बाकी की जगह नहीं लेता। Docker run विकल्प, seccomp, नेटवर्क आइसोलेशन।

अस्थायी डायरेक्टरी का noexec विकल्प उस माउंट से सीधे एक्ज़ीक्यूशन को रोकता है, लेकिन इंटरप्रेटर वहां रखी स्क्रिप्ट को पढ़कर चला सकता है। यह यूज़र प्रोग्राम पर रोक नहीं लगाता। 128-MiB की लिमिट भी इन छोटे उदाहरणों के लिए सही है, हर npm पैकेज या डेटा साइंस वर्कलोड के लिए नहीं।

शेल इंटरपोलेशन के बिना इसे बैकएंड से जोड़ें

भरोसेमंद वर्कर पर तय आर्ग्युमेंट से Docker या प्रोवाइडर रिक्वेस्ट बनाएँ। Node में spawn को shell: false के साथ इस्तेमाल कर सकते हैं; Python में आर्ग्युमेंट की सूची के साथ subprocess.Popen इस्तेमाल कर सकते हैं। सबमिट किया गया सोर्स stdin या तय फ़ाइल पाथ से भेजें। उसे कभी शेल कमांड के अंदर न रखें, जैसे sh -c को पास की गई स्ट्रिंग में। Node चाइल्ड प्रोसेस और Python subprocess सुरक्षा देखें।

यूज़र को मंज़ूर किए गए रनटाइम नामों में से चुनने दें। रिक्वेस्ट को Docker फ़्लैग, मनमानी इमेज, होस्ट पाथ या एनवायरनमेंट वेरिएबल के नाम देने की अनुमति न दें। पैकेज इंस्टॉल करने से भी कोड चलता है; अगर आप इसे सपोर्ट करते हैं, तो इसे उसी आइसोलेशन और रिसोर्स पॉलिसी के अंदर चलाएँ।

वर्कलोड रोकें, आउटपुट सीमित करें और क्लीनअप की पुष्टि करें

HTTP रिक्वेस्ट या SDK कॉल पर लगा टाइमआउट आपके बैकएंड का इंतज़ार खत्म कर सकता है, जबकि रिमोट प्रोग्राम चलता रहता है। इसी तरह, लोकल Docker CLI प्रोसेस खत्म करने पर उसका कंटेनर चलता रह सकता है।

भरोसेमंद सुपरवाइज़र को ये काम करने चाहिए:

• एक्ज़ीक्यूशन शुरू होने से पहले कंटेनर या सैंडबॉक्स ID दर्ज करें।
• stdout और stderr को थोड़ा-थोड़ा पढ़ें और दोनों के लिए कुल बाइट की साझा लिमिट रखें।
• टाइमआउट या ज़्यादा आउटपुट आने पर रनटाइम API से असली वर्कलोड रोकें।
• असीमित डेटा रखे बिना जुड़ी हुई स्ट्रीम बंद करें या खाली करें।
• वर्कलोड खत्म होने की पुष्टि करें, अस्थायी स्टेट हटाएँ और क्लीनअप की किसी भी विफलता को दर्ज करें।

उदाहरणों में --log-driver none Docker को कंटेनर लॉग रखने से रोकता है। आपके बैकएंड को फिर भी पढ़ी जाने वाली स्ट्रीम पर लिमिट लगानी होगी। Docker के लिए जुड़ी हुई CLI खत्म करने से पहले संबंधित नाम वाला कंटेनर रोकें। microVM सर्विस के लिए उसके डॉक्यूमेंटेशन में दिया गया समाप्ति ऑपरेशन इस्तेमाल करें और अंतिम स्टेट की पुष्टि करें।

जहां उपलब्ध हो, प्रोवाइडर की ओर से एक्सपायरी सेट करें। वर्कर की बिजली जाने के बाद finally ब्लॉक नहीं चल सकता, इसलिए तय समय पर चलने वाली क्लीनअप प्रक्रिया रखें जो समय पूरा कर चुके जॉब रिकॉर्ड का चालू रिसोर्स से मिलान करे। क्लीनअप ऐसा बनाएँ कि उसे दोहराना सुरक्षित हो। सिर्फ़ क्लाइंट के डिस्कनेक्ट होने से किसी छूटे हुए जॉब का क्लीनअप सफल न मानें।

हमने क्या जांचा

31 अक्टूबर 2026 को हमने दोनों कमांड Docker Desktop पर Engine 28.1.1, Linux कर्नेल 6.10.14-linuxkit, ARM64, Node.js 24.22.2 और Python 3.13.18 के साथ चलाईं।

हमारी पहली आउटपुट लिमिट जांच में क्लीनअप का बग मिला: कंटेनर रुकने के बाद जुड़ी हुई Docker CLI भरे हुए पाइप पर इंतज़ार करती रही। हमने टेस्ट सुपरवाइज़र ठीक किया, ताकि वह पहले वर्कलोड खत्म करे, फिर जुड़े हुए क्लाइंट को बंद करे। इसीलिए अकेली लॉन्च कमांड पूरा रनर नहीं है।

ये जांचें लोकल कंटेनर कॉन्फ़िगरेशन और सुपरवाइज़र के व्यवहार को कवर करती हैं। ये कर्नेल से बाहर निकलने के तरीकों को टेस्ट नहीं करतीं, यह साबित नहीं करतीं कि एक्सेस का हर रास्ता ब्लॉक है, और Lizard के microVM आइसोलेशन को भी टेस्ट नहीं करतीं। ये जांचें उस असली वर्कर रनटाइम पर दोहराएँ जिसे आप डिप्लॉय करते हैं।

नतीजों और सेव किए गए स्टेट को भी अविश्वसनीय मानें

सैंडबॉक्स प्रोग्राम को सीमित रख सकता है, जबकि उसका आउटपुट अगले सिस्टम पर हमला करे। stdout को रेंडर करने से पहले एस्केप करें। लौटे हुए JSON को जांचें। सबमिट किए गए Python pickle को कभी डीसिरियलाइज़ न करें और लौटाई गई JavaScript स्ट्रिंग को बैकएंड में कभी इवैल्यूएट न करें। Python pickle चेतावनी, OWASP आउटपुट हैंडलिंग।

बनाए गए HTML और प्रीव्यू ऐसे ओरिजिन से सर्व करें जो आपके डैशबोर्ड के क्रेडेंशियल साझा न करे। डाउनलोड की जाने वाली फ़ाइलों के नाम, आकार और प्रकार कंट्रोल करें; गेस्ट के बनाए सिमलिंक से होस्ट पाथ तक जाने से बचें। आर्काइव निकालने और डीकम्प्रेशन के काम को भी सीमित करें।

नया स्टेट एक टेनेंट को दूसरे टेनेंट की फ़ाइलें, पैकेज कैश या मेमोरी में रखे मान पढ़ने से रोकता है। बने रहने वाले सेशन के लिए स्वामित्व और डेटा रखने के साफ़ नियम चाहिए। पॉज़ किया गया सैंडबॉक्स स्टेट रखता है; उसे अगले यूज़र का साफ़ एनवायरनमेंट नहीं बनना चाहिए। स्नैपशॉट और साझा वॉल्यूम पर भी यही नियम लागू करें।

Lizard की भूमिका

Lizard Sandboxes Firecracker microVM में कोड चलाता है, जिनमें से हर एक का अपना कर्नेल होता है। Lizard SDK JavaScript/TypeScript और Python सपोर्ट करता है, जिसमें फ़ाइल ऑपरेशन, कमांड एक्ज़ीक्यूशन, स्टेटस जांच और लाइफ़साइकल कंट्रोल शामिल हैं। आपका बैकएंड अपने वर्कर होस्ट चलाने के बजाय उस API से एक्ज़ीक्यूशन एनवायरनमेंट मैनेज कर सकता है। Lizard Sandboxes डॉक्यूमेंटेशन।

मैनेजमेंट API कुंजी बैकएंड में रखें। नुकसान पहुंचाने वाले कोड के जॉब में lizardToken पास करने से बचें, जो गेस्ट के अंदर प्रोजेक्ट क्रेडेंशियल चालू करता है। ऐसे एजेंट क्रेडेंशियल भी न जोड़ें जिनकी टास्क को ज़रूरत नहीं है। लाइफ़टाइम साफ़ तौर पर सेट करें और सीमित नतीजे इकट्ठा करने के बाद अस्थायी जॉब खत्म करें। Lizard SDK रेफ़रेंस।

Firecracker आइसोलेशन का मतलब आउटबाउंड ट्रैफ़िक ब्लॉक होना नहीं है। जांचें कि डिप्लॉय की गई नेटवर्क पॉलिसी आपके ज़रूरी डेस्टिनेशन की पाबंदियां लागू करती है। मौजूदा SDK create-options रेफ़रेंस में आउटबाउंड अलाउलिस्ट दर्ज नहीं है; कोई फ़्लैग गढ़ें नहीं और यह न मानें कि गेस्ट की प्रॉक्सी सेटिंग इसे लागू करती है। अगर सख़्त आउटबाउंड कंट्रोल ज़रूरी है, तो वह वर्कलोड स्वीकार करने से पहले ऐसा कॉन्फ़िगरेशन वेरिफ़ाई करें जो ये पाबंदियां लागू कर सके।

पहले जॉब की अनुमति वाली फ़ाइलें, नेटवर्क एक्सेस और रिसोर्स बजट तय करें। फिर उन पाबंदियों के साथ नया एनवायरनमेंट टेस्ट करें। एक्ज़ीक्यूशन API के लिए Lizard क्विकस्टार्ट और लागत का अनुमान लगाने के लिए हमारी सैंडबॉक्स प्राइसिंग तुलना इस्तेमाल करें।