सुरक्षा ऑडिट के परिणाम: मुझे शर्मिंदगी क्यों महसूस हुई
मैंने हाल ही में अपने सभी साइड प्रोजेक्ट्स पर एक सुरक्षा ऑडिट (security audit) किया। इसमें मेरा FastAPI बैकएंड, Telegram बॉट्स, PWA और Streamlit ऐप्स शामिल हैं।
मुझे लगा था कि मेरा कोड सुरक्षित है क्योंकि मैं सावधान था। मैं गलत था।
मैं ये वास्तविक प्रोडक्शन बग्स (production bugs) आपके साथ साझा कर रहा हूँ ताकि आप इनसे बच सकें। ये कोई सैद्धांतिक चेकलिस्ट नहीं हैं। ये वे गलतियाँ हैं जो मैंने वास्तव में की हैं।
कंडीशनल ऑथेंटिकेशन का जाल (The Conditional Authentication Trap) मैंने ऐसा कोड लिखा था जो वेरिफिकेशन करने से पहले यह चेक करता था कि क्या API सीक्रेट मौजूद है। यदि एनवायरनमेंट वेरिएबल (environment variable) गायब होता, तो चेक पूरी तरह से स्किप हो जाता था। इसका मतलब था कि मेरा पूरा API जनता के लिए खुला था। नियम: यदि कोई सीक्रेट गायब है, तो 500 एरर के साथ प्रक्रिया को तुरंत रोक दें। ऑथेंटिकेशन को कभी भी स्किप न करें।
Git हिस्ट्री लीक (The Git History Leak) मैंने एक बार त्वरित परीक्षण के लिए एक API की (key) को हार्डकोड कर दिया था। बाद में मैंने इसे .env फ़ाइल में स्थानांतरित कर दिया और सोचा कि यह ठीक हो गया है। लेकिन Git सब कुछ याद रखता है। कोई भी मेरी कमिट हिस्ट्री (commit history) में उस की (key) को ढूंढ सकता है। नियम: यदि आप कोई की (key) कमिट करते हैं, तो मान लें कि वह चोरी हो गई है। उसे तुरंत बदलें (rotate)। अपनी हिस्ट्री साफ़ करने के लिए git-filter-repo का उपयोग करें।
डिबग एंडपॉइंट लीक (The Debug Endpoint Leak) मैंने समस्या निवारण (troubleshoot) में मदद के लिए प्रोडक्शन में एक
/debug/configएंडपॉइंट छोड़ दिया था। इसने मेरे डेटाबेस URL और एनवायरनमेंट सेटिंग्स को उजागर कर दिया। नियम: डिप्लॉयमेंट से पहले सभी डिबग एंडपॉइंट्स हटा दें। इसके बजाय लॉग्स (logs) का उपयोग करें।एरर्स के माध्यम से सिस्टम जानकारी लीक होना (Leaking System Info via Errors) मैंने अपने एरर रिस्पॉन्स में
str(e)का उपयोग किया था। इससे डेटाबेस एरर और फ़ाइल पाथ सीधे उपयोगकर्ता को चले जाते थे। हमलावर आपके इंफ्रास्ट्रक्चर का पता लगाने के लिए इसका उपयोग करते हैं। नियम: अपने लिए विस्तृत एरर लॉग करें। क्लाइंट को एक सामान्य "Internal Server Error" भेजें।फ्रंटएंड में XSS का जोखिम (The XSS Risk in Frontend) मैंने यूजर कंटेंट को रेंडर करने के लिए
innerHTMLका उपयोग किया था। इससे अन्य उपयोगकर्ताओं के ब्राउज़र में स्क्रिप्ट चलाने की अनुमति मिल गई। नियम: हमेशा HTML को एस्केप (escape) करें।innerHTMLको मनमाना कोड (arbitrary code) चलाने के तरीके के रूप में देखें।रेट लिमिट्स की कमी (Missing Rate Limits) मेरे पास ऐसे एंडपॉइंट्स थे जो बिना किसी सीमा के महंगे AI मॉडल को कॉल करते थे। एक सिंगल लूप या चोरी की गई की (key) मुझे सैकड़ों डॉलर का नुकसान पहुँचा सकती थी। नियम: ऑथेंटिकेशन अनधिकृत उपयोगकर्ताओं को रोकता है। रेट लिमिटिंग अधिकृत उपयोगकर्ताओं को आपके सिस्टम का दुरुपयोग करने से रोकती है।
अनुमति देने वाली CORS पॉलिसी (Permissive CORS Policy) मैंने प्रोडक्शन में
allow_origins=["*"]का उपयोग किया था। यह किसी भी साइट को आपके API पर रिक्वेस्ट भेजने की अनुमति देता है। नियम: केवल अपने विशिष्ट फ्रंटएंड डोमेन की अनुमति दें।अस्थायी फ़ाइल लीक यदि फ़ाइल प्रोसेस करते समय मेरा कोड क्रैश हो जाता है, तो अस्थायी फ़ाइल हमेशा के लिए डिस्क पर रह जाती है। इससे जगह बर्बाद होती है और संवेदनशील डेटा लीक हो जाता है। नियम: यह सुनिश्चित करने के लिए कि त्रुटि होने पर भी फ़ाइलें डिलीट हो जाएं, try-finally ब्लॉक्स का उपयोग करें।
मेरी नई अनिवार्य चेकलिस्ट:
कोडिंग से पहले: • एक .gitignore बनाएँ • एक .env.example बनाएँ
प्रत्येक एंडपॉइंट के लिए: • ऑथेंटिकेशन जोड़ें • सामान्य त्रुटि संदेशों का उपयोग करें • भारी कार्यों के लिए रेट लिमिट जोड़ें
कमिट करने से पहले: • अपने डिफ में सीक्रेट्स के लिए स्कैन करें
डिप्लॉय करने से पहले: • अपनी डिपेंडेंसीज़ पर सुरक्षा ऑडिट चलाएँ
सुरक्षा संबंधी समस्याएँ अचानक नहीं होतीं। वे "TODO" कमेंट्स और "अस्थायी" सुधारों के कारण होती हैं जो हमेशा के लिए प्रोडक्शन में रह जाते हैं।
बग को ठीक करना उबाऊ है। ब्रीच को ठीक करना महंगा है।