Production Website का Security Audit — 10 Badi Vulnerabilities, Unke Real Risks और Practical Solutions

डेवलपर्स के तौर पर, हमारा प्राइमरी फोकस हमेशा नए Features ship करने, Clean Architecture design करने, और Smooth UI deliver करने पर होता है। जब एप्लीकेशन प्रोडक्शन पर सक्सेसफुली लाइव हो जाती है और बिना किसी App Crash या error के चलने लगती है, तो हम assume कर लेते हैं कि हमारा सिस्टम Rock-Solid है।

लेकिन "App smoothly काम कर रही है" और "App fully secure है" — इन दोनों बातों में ज़मीन-आसमान का फ़र्क है।

कुछ हफ्ते पहले मैंने एक लाइव प्रोडक्शन वेब ऐप पर एक thorough Security Audit कन्डक्ट किया। एप्लीकेशन काफी टाइम से लाइव थी, कोर बिज़नेस लॉजिक संभाल रही थी (payments, user authentication, dynamic file uploads), और सरफेस लेवल पर सब कुछ परफेक्टली चल रहा था।

जब ऑडिट रिपोर्ट सामने आई, तो उसने एक डेवलपर के रूप में मेरी आँखें खोल दीं। High-level analysis में 10 ऐसी बड़ी vulnerabilities मिलीं जो किसी भी लाइव प्लेटफॉर्म को पल भर में compromise कर सकती हैं।

इस आर्टिकल में, हम बिना किसी कॉम्प्लेक्स कोड या डीप टेक्निकल डिटेल्स में गए — डायरेक्ट Vulnerabilities, उनके Real-World Risks और उनके Practical Solutions पर बात करेंगे।

1. Unauthenticated File Uploads

⚠️ Risk:

अगर आपकी वेबसाइट पर कोई ऐसा अपलोड सेक्शन है जहाँ बिना लॉगिन चेक के फाइल्स एक्सेप्ट हो रही हैं, तो यह एक खुला निमंत्रण है। Attacker यहाँ किसी भी तरह की Malicious Script या Phishing HTML File अपलोड कर सकता है। इसका सबसे बड़ा रिस्क यह है कि हैकर आपके ही ऑफिशियल डोमेन का यूज़ करके Fake Login Pages होस्ट कर सकता है, जिससे Google आपकी पूरी डोमेन को Phishing Warning देकर ब्लैकलिस्ट कर देगा। इसके अलावा, ऑटोमेटेड बॉट्स हैवी फाइल्स अपलोड करके आपका Cloud Storage Bill एक्स्ट्रा बढ़ा सकते हैं।

💡 Solution:

अपलोड सिस्टम के स्टार्टिंग में ही Session Authentication कम्पलशन लगाएँ और स्ट्रिक्टली स्पेसिफाई करें कि सिस्टम सिर्फ सेफ फाइल फॉर्मेट्स (जैसे JPEG, PNG, PDF) ही एक्सेप्ट करे।

2. Dev Mode Conditionals in Production

⚠️ Risk:

लोकल डेवलपमेंट के वक्त टेस्टिंग फास्ट करने के लिए हम अक्सर टेम्परेरी लॉजिक डाल देते हैं (जैसे "Dev mode है तो पासवर्ड चेक स्किप कर दो")। रिस्क तब पैदा होता है जब डिप्लॉयमेंट पाइपलाइन (Vercel, Docker या AWS) में गलती से एनवायरनमेंट कॉन्फ़िगरेशन मिसकॉन्फ़िगर हो जाए। ऐसे में इंटरनेट पर बैठा कोई भी यूजर बिना किसी पासवर्ड के डायरेक्ट Full Admin Access क्लेम कर सकता है।

💡 Solution:

कोर सिक्योरिटी लॉजिक के अंदर कभी भी Environment-Based Conditionals मत रखें। लोकल टेस्टिंग के लिए डेडिकेटेड मॉक्स या लोकल डेटाबेस सीडर्स का यूज़ करें और प्रोडक्शन रिलीज़ से पहले कोडबेस को थोरॉली रिव्यू करें।

3. Dynamic Database Queries (SQL Injection Risk)

⚠️ Risk:

जब यूजर के इनपुट (जैसे सर्च फील्ड, फ़िल्टर्स या सॉर्टिंग ऑप्शंस) को बिना वैलिडेट किए सीधा डेटाबेस क्वेरी में पास किया जाता है, तो अटैकर वहाँ मैलिशियस डेटाबेस कमांड्स इंजेक्ट कर सकता है। इसका सबसे बड़ा रिस्क यह है कि अटैकर एक सिंगल रिक्वेस्ट से आपके पूरे डेटाबेस को रीड कर सकता है या एक ही झटके में पता चलने वाले सारे टेबल्स डिलीट (wipe out) कर सकता है।

💡 Solution:

यूजर इनपुट्स पर हमेशा स्ट्रिक्ट Whitelisting लगाएँ (पहले से तय करें कि कौन से वैल्यूज़ अलाउड हैं) और ORM या Query Parameterization का यूज़ करें ताकि यूजर इनपुट हमेशा प्लेन टेक्स्ट की तरह ट्रीट हो, कमांड की तरह नहीं।

4. Plaintext Storage of OTPs & Sensitive Logs

⚠️ Risk:

डिबगिंग के वक्त जनरेटेड OTPs या टोकन्स को टेम्परेरी लॉग फाइल्स में .txt फॉर्मेट में सेव कर देना एक आम गलती है। अगर सर्वर पर छोटा सा भी कॉन्फ़िगरेशन फ्लॉ या पाथ-रीडिंग वल्नरेबिलिटी आती है, तो अटैकर इन लॉग फाइल्स को पढ़कर किसी भी एक्टिव यूजर का लाइव OTP देख सकता है और इंस्टेंटली अकाउंट टेकओवर कर सकता है।

💡 Solution:

सेंसिटिव टेम्परेरी डेटा (OTPs, Tokens) को कभी भी लोकल डिस्क पर प्लेनटेक्स्ट फाइल्स में सेव न करें। उन्हें एन्क्रिप्टेड/हैश्ड फॉर्म में फास्ट टेम्परेरी मेमोरी स्टोर्स (जैसे Redis) में शॉर्ट एक्सपायरी टाइम के साथ रखें।

5. Hardcoded Fallback Credentials

⚠️ Risk:

अक्सर ऐप क्रैश होने से बचाने के लिए कोड में फॉलबैक पासवर्ड्स या कीज़ सेट कर दी जाती हैं (e.g. "अगर मेन की नहीं मिले तो डिफॉल्ट की यूज़ कर लो")। अगर कभी सिस्टम कॉन्फ़िगरेशन फेल होती है, तो यह गेसेबल, हार्डकोडेड की ही आपकी प्राइमरी सिक्योरिटी बन जाती है। अटैकर्स पब्लिक डिफॉल्ट कीज़ का यूज़ करके Fake Admin Tokens generate कर सकते हैं।

💡 Solution:

सिक्योरिटी कीज़ के लिए कभी भी डिफॉल्ट फॉलबैक मत रखें। अगर ज़रूरी एनवायरनमेंट वेरिएबल्स मिसिंग हैं, तो सिस्टम को Fail Fast होने दें (ऐप को स्टार्टअप पर ही स्टॉप होने दें) — वीक सिक्योरिटी के साथ ऐप चलाने से ऐप का बंद होना कहीं बेहतर है।

6. Missing Rate Limiting (Brute-Force Attack)

⚠️ Risk:

अगर आपके लॉगिन, OTP वेरिफिकेशन या पासवर्ड रीसेट फॉर्म्स पर रिक्वेस्ट लिमिट नहीं लगी है, तो अटैकर ऑटोमेटेड स्क्रिप्ट्स का यूज़ करके सेकंड्स में हज़ारों गेसेस ट्राई कर सकता है। एक 6-digit OTP में लिमिटेड कॉम्बिनेशंस होते हैं — बिना रेट लिमिट के, 10-15 मिनट के अंदर (OTP एक्सपायर होने से पहले) करेक्ट कॉम्बिनेशन क्रैक हो जाएगा।

💡 Solution:

हर ऑथेंटिकेशन एंडपॉइंट पर स्ट्रिक्ट Rate Limiting Middleware अप्लाई करें (for example: "5 गलत अटैम्प्स के बाद यूजर को 15 मिनट के लिए लॉक कर दो")।

7. Outdated Packages & Known CVEs

⚠️ Risk:

आपका कोड कितना भी क्लीन हो, अगर आपकी अंडरलाइंग थर्ड-पार्टी लाइब्रेरीज़ (npm/pip packages) पुरानी हैं, तो उनमें पहले से पब्लिकली नोवेड सिक्योरिटी बग्स (CVEs) मौजूद होते हैं। ऑटोमेटेड बॉट्स कंटीन्यूअसली इंटरनेट पर ऐसी साइट्स को स्कैन करते हैं और पुरानी लाइब्रेरीज़ का फायदा उठाकर Remote Code Execution (RCE) या सर्वर क्रैश कर देते हैं।

💡 Solution:

मंथली बेसिस पर डिपेंडेंसी ऑडिट्स (npm audit) रन करें और रिपॉजिटरी में ऑटोमेटेड डिपेंडेंसी अपडेट टूल्स (जैसे Dependabot या Snyk) इनेबल करें।

8. Missing HTTP Security Headers

⚠️ Risk:

अगर आपके वेब सर्वर से बेसिक सिक्योरिटी हेडर्स मिसिंग हैं, तो ब्राउज़र-लेवल अटैक्स का खतरा बढ़ जाता है। For example, Clickjacking में अटैकर आपकी वेबसाइट को एक इनविजिबल आईफ्रेम (iframe) में अपनी किसी फेक साइट पर एम्बेड कर देता है — यूजर को लगता है वो किसी क्विज़ पर क्लिक कर रहा है, पर एक्चुअल में क्लिक आपकी साइट के इनविजिबल "Delete Account" या "Payment" बटन पर हो रहा होता है।

💡 Solution:

सर्वर लेवल या Next.js कॉन्फिग पर स्टैंडर्ड सिक्योरिटी हेडर्स (जैसे CSP, X-Frame-Options: DENY, HSTS) इंजेक्ट करें ताकि ब्राउज़र खुद इन अटैक्स को ब्लॉक कर दे।

9. Non-HttpOnly Session Storage

⚠️ Risk:

लॉगिन टोकन्स या JWTs को अगर ब्राउज़र के localStorage या नॉर्मल एक्सेसिबल कुकीज़ में रखा जाए, तो साइट पर आया कोई भी छोटा सा क्लाइंट-साइड स्क्रिप्ट बग (XSS) इन टोकन्स को पढ़ सकता है। अटैकर जावास्क्रिप्ट के ज़रिए टोकन चुरा कर अपने ब्राउज़र में पेस्ट करेगा और आपका सेशन हाइजैक कर लेगा।

💡 Solution:

सेशन/ऑथ टोकन्स को हमेशा बैकएंड से HttpOnly + Secure + SameSite=Strict फ्लैग्स के साथ ही कुकी में सेंड करें, ताकि क्लाइंट-साइड जावास्क्रिप्ट उसे कभी रीड ही न कर सके।

Full Security Audit Overview