वेबसाइट सुरक्षा जाँच जो आप बिना कुछ हैक किए कर सकते हैं

किसी ऑनलाइन स्टोर के सिक्योरिटी सेटअप का बड़ा हिस्सा आप बाहर से ही जाँच सकते हैं, बस यह पढ़कर कि साइट हर विज़िटर को पहले से क्या भेजती है: उसका TLS सर्टिफ़िकेट, रीडायरेक्ट, HTTP रिस्पॉन्स हेडर, कुकीज़, वह जो स्क्रिप्ट लोड करती है और उसके पब्लिक DNS रिकॉर्ड। ये पैसिव जाँचें कोई अटैक ट्रैफ़िक नहीं भेजतीं और इनके लिए लॉगिन की ज़रूरत नहीं होती, इसलिए ये स्टोर पर किसी सामान्य विज़िट से ज़्यादा लोड नहीं डालतीं। ये कॉन्फ़िगरेशन की कमियाँ पकड़ती हैं, जैसे एक्सपायर होने वाला सर्टिफ़िकेट, गायब HSTS, असुरक्षित कुकीज़, मिक्स्ड कंटेंट या ज्ञात कमियों वाला jQuery वर्ज़न। ये पेनिट्रेशन टेस्ट नहीं हैं और यह साबित नहीं कर सकतीं कि स्टोर सुरक्षित है।

मुख्य बातें

• 15 मार्च 2026 से जारी सार्वजनिक रूप से भरोसेमंद (publicly trusted) TLS सर्टिफ़िकेट ज़्यादा से ज़्यादा 200 दिन तक वैध रह सकते हैं; मार्च 2027 में यह सीमा 100 दिन और मार्च 2029 में 47 दिन हो जाएगी (CA/Browser Forum (नए टैब में खुलता है))।
• जब HSTS हेडर सादे HTTP पर भेजा जाता है, तो ब्राउज़र उसे अनदेखा कर देते हैं (MDN (नए टैब में खुलता है))।
• CSP का frame-ancestors डायरेक्टिव <meta> टैग में काम नहीं करता; इसे रिस्पॉन्स हेडर में ही भेजना होगा (MDN (नए टैब में खुलता है))।
• 3.5.0 से पहले के jQuery वर्ज़न दो XSS कमज़ोरियों से प्रभावित हैं, और CISA ने इनमें से एक, CVE-2020-11023, को 23 जनवरी 2025 को अपने Known Exploited Vulnerabilities कैटलॉग में जोड़ा (NVD (नए टैब में खुलता है))।
• security.txt फ़ाइल में Contact और Expires फ़ील्ड होने चाहिए और यह /.well-known/security.txt पर होनी चाहिए (RFC 9116 (नए टैब में खुलता है))।

पैसिव सिक्योरिटी चेक किसे कहते हैं?

पैसिव चेक सिर्फ़ वही पढ़ता है जो साइट या उसका DNS किसी सामान्य रिक्वेस्ट के जवाब में लौटाता है।

इसका मतलब है पब्लिक पेज लोड करना, सर्टिफ़िकेट और रिस्पॉन्स हेडर पढ़ना, किसी पेज की सेट की गई कुकीज़ और लोड की गई स्क्रिप्ट की सूची बनाना, और पब्लिक DNS रिकॉर्ड क्वेरी करना। पैसिव चेक पासवर्ड का अंदाज़ा नहीं लगाता, इंजेक्शन पेलोड नहीं भेजता, एडमिन URL नहीं टटोलता और पोर्ट स्कैन नहीं करता। नीचे दी गई हर जाँच ब्राउज़र, curl, openssl और dig से की जा सकती है।

अपना TLS सर्टिफ़िकेट और उसकी एक्सपायरी कैसे जाँचें?

सर्टिफ़िकेट की तारीख़ें और नाम सीधे पढ़ें, और पक्का करें कि रिन्यूअल ऑटोमेटेड है।

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -subject -issuer -dates

जाँचें कि notAfter की तारीख़ आराम से भविष्य में है, कि अगर आप example.com और www.example.com दोनों इस्तेमाल करते हैं तो सर्टिफ़िकेट दोनों को कवर करता है (ब्राउज़र का सर्टिफ़िकेट व्यूअर नाम दिखाता है), और कि ब्राउज़र कोई चेतावनी नहीं दिखाता। CA/Browser Forum Baseline Requirements (सेक्शन 6.3.2, अक्टूबर 2026 की स्थिति में वर्ज़न 2.3.1) के तहत सर्टिफ़िकेट की वैधता अवधि घट रही है; यह 11 अप्रैल 2025 को अपनाए गए Ballot SC-081v3 (नए टैब में खुलता है) के बाद हुआ है:

कम वैधता अवधि की वजह से मैन्युअल रिन्यूअल जोखिम भरा है, इसलिए पक्का करें कि आपका होस्ट या सर्टिफ़िकेट टूल अपने आप रिन्यू करता है। यह भी पक्का करें कि सादा HTTP, HTTPS पर रीडायरेक्ट होता है:

curl -sI http://example.com/ | grep -i -E "^HTTP|^location"

आपको 301 (या 308) रिस्पॉन्स चाहिए, जिसका location हेडर https:// से शुरू हो।

ऑनलाइन स्टोर को कौन से सिक्योरिटी हेडर भेजने चाहिए?

रिस्पॉन्स हेडर का एक छोटा सेट लगभग बिना किसी लागत के ब्राउज़र की तरफ़ होने वाले आम हमलों को रोकता है।

देखें कि आपका स्टोर क्या भेजता है:

curl -sI https://example.com/

Strict-Transport-Security: max-age=31536000; includeSubDomains
Content-Security-Policy: frame-ancestors 'self'
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin

दो सावधानियाँ। includeSubDomains ऐसे हर सबडोमेन को ब्लॉक कर देता है जो सिर्फ़ HTTP पर चलता है, इसलिए पहले सबडोमेन जाँच लें। HSTS preloading के लिए कम से कम 31536000 का max-age और includeSubDomains चाहिए, इसलिए preload तभी जोड़ें जब हर सबडोमेन HTTPS के लिए तैयार हो। स्क्रिप्ट को सीमित करने वाली पूरी CSP रखना फ़ायदेमंद है, लेकिन OWASP बताता है कि इसे कॉन्फ़िगर और मेंटेन करना जटिल है, और कई ऐप वाले स्टोर्स को इसे ध्यान से टेस्ट करना चाहिए।

क्या आपकी कुकीज़ Secure, HttpOnly और SameSite के साथ सेट हैं?

सेशन और कार्ट कुकीज़ पर ये तीनों एट्रिब्यूट होने चाहिए, और आप इन्हें Set-Cookie रिस्पॉन्स हेडर में देख सकते हैं।

अगर कोई SameSite एट्रिब्यूट सेट नहीं है, तो ब्राउज़र कुकी को Lax मानते हैं। जिन कुकीज़ को आपकी अपनी स्क्रिप्ट्स को पढ़ना होता है, वे HttpOnly नहीं हो सकतीं, इसलिए उन कुकीज़ पर ध्यान दें जो लॉग-इन ग्राहक या एडमिन की पहचान करती हैं।

curl -sI https://example.com/ | grep -i "^set-cookie"

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

मिक्स्ड कंटेंट कैसे खोजें?

मिक्स्ड कंटेंट ऐसा कोई भी रिसोर्स है जो HTTPS पर दिए गए पेज पर HTTP से लोड होता है, और ब्राउज़र कंसोल इसकी सूची दिखाता है।

MDN (नए टैब में खुलता है) इसे दो समूहों में बाँटता है। इमेज, ऑडियो और वीडियो “upgradable” हैं: ब्राउज़र इन्हें अपने आप HTTPS पर माँगते हैं। स्क्रिप्ट, स्टाइलशीट, iframe, फ़ॉन्ट और fetch() रिक्वेस्ट “blockable” हैं: ब्राउज़र इन्हें ब्लॉक कर देते हैं, जिससे इन पर निर्भर हर चीज़ टूट जाती है। किसी सीधे IP एड्रेस पर अपग्रेड की गई रिक्वेस्ट भी ब्लॉक होती हैं।

इसे खोजने के लिए अपने मुख्य टेम्पलेट्स (होम, कलेक्शन, प्रोडक्ट, कार्ट) पर कंसोल खोलें और अपने थीम कोड, पेज कंटेंट और ऐप सेटिंग्स में http:// खोजें। Shopify का हेल्प सेंटर कहता है कि स्टोर का कोई भी पेज, जिसका कोई एसेट HTTPS पर नहीं आता, असुरक्षित माना जाता है (नए टैब में खुलता है), और एसेट्स को Shopify पर होस्ट करने या HTTPS पर देने की सलाह देता है। WooCommerce पर, अगर साइट कभी http:// पर चली थी, तो पुराने पोस्ट कंटेंट और थीम विकल्प जाँचें।

ज्ञात CVE वाली पुरानी JavaScript लाइब्रेरी कैसे पहचानें?

हर पेज जो लाइब्रेरी लोड करता है, उनकी सूची बनाएँ, उनके वर्ज़न पढ़ें, और उनकी तुलना National Vulnerability Database से करें।

jQuery से शुरू करें। ब्राउज़र कंसोल में $.fn.jquery लोड हुआ वर्ज़न बताता है (jQuery API (नए टैब में खुलता है))। इन वर्ज़न पर ध्यान दें:

2020 की दोनों समस्याएँ jQuery 3.5.0 में ठीक कर दी गई हैं। कमज़ोर वर्ज़न का मतलब है कि कमी वाला कोड मौजूद है; उसका फ़ायदा उठाया जा सकता है या नहीं, यह इस पर निर्भर है कि साइट उसे डेटा कैसे देती है। WordPress वर्ज़न 5.6 से (नए टैब में खुलता है) jQuery 3.5.1 के साथ आता है, इसलिए WooCommerce स्टोर पर पुराना jQuery या तो पुराने WordPress की ओर इशारा करता है या किसी ऐसी थीम या प्लगइन की ओर जो अपनी अलग कॉपी लोड करता है। Shopify पर अपनी थीम फ़ाइलें और स्क्रिप्ट जोड़ने वाले ऐप जाँचें।

security.txt क्या है और क्या आपके स्टोर को इसकी ज़रूरत है?

यह एक सादी टेक्स्ट फ़ाइल है जो सिक्योरिटी रिसर्चर्स को बताती है कि वे आपको किसी कमज़ोरी की रिपोर्ट कैसे करें।

RFC 9116 (नए टैब में खुलता है) (अप्रैल 2022, एक Informational RFC, इसलिए इसका पालन स्वैच्छिक है) कहता है कि फ़ाइल HTTPS पर /.well-known/security.txt पर text/plain के रूप में दी जानी चाहिए। Contact और Expires ज़रूरी हैं, और RFC सलाह देता है कि Expires की तारीख़ एक साल से कम आगे की हो।

Contact: mailto:security@example.com
Expires: 2027-09-30T23:00:00.000Z
Preferred-Languages: en
Policy: https://example.com/security-policy

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

DMARC आपके स्टोर को ईमेल स्पूफ़िंग से कैसे बचाता है?

DMARC से आप मेलबॉक्स प्रोवाइडर्स से कह सकते हैं कि जो ईमेल From एड्रेस में आपका डोमेन इस्तेमाल करते हैं लेकिन अलाइन SPF या DKIM पास नहीं करते, उन्हें क्वारंटीन या रिजेक्ट करें।

p=none वाला रिकॉर्ड सिर्फ़ रिपोर्ट्स जुटाता है; यह स्पूफ़ किए गए ईमेल नहीं रोकता। ग्राहक ऑर्डर कन्फ़र्मेशन और पासवर्ड रीसेट आपके डोमेन से आने की उम्मीद करते हैं, इसलिए आपका हूबहू डोमेन दिखाने वाले फ़िशिंग मैसेज को ब्लॉक करना ज़रूरी है। अपनी पॉलिसी dig +short TXT _dmarc.example.com से जाँचें, और स्पेसिफ़िकेशन के लिए RFC 9989 (नए टैब में खुलता है) देखें। DMARC मिलते-जुलते (lookalike) डोमेन को कवर नहीं करता, सिर्फ़ उस डोमेन को करता है जो रिकॉर्ड पब्लिश करता है।

Shopify क्या मैनेज करता है, और WooCommerce पर आपके नियंत्रण में क्या है?

Shopify अपने स्टोरफ़्रंट के पीछे के सर्वर ख़ुद चलाता है, जबकि सेल्फ़-होस्टेड WooCommerce स्टोर में सर्वर सेटिंग्स आपकी और आपके होस्ट की ज़िम्मेदारी होती हैं।

अक्टूबर 2026 में जब हमने Shopify पर होस्ट किए गए कई स्टोरफ़्रंट जाँचे, तो उनके रिस्पॉन्स में लगभग 91 दिन के max-age वाला HSTS, X-Content-Type-Options: nosniff और upgrade-insecure-requests वाली CSP थी, जबकि frame-ancestors अलग-अलग स्टोर में अलग था। Shopify कहता है कि वह Level 1 PCI DSS compliant के रूप में प्रमाणित (नए टैब में खुलता है) है। आपकी थीम और इंस्टॉल किए गए ऐप आपकी ज़िम्मेदारी बने रहते हैं।

WooCommerce पर WordPress की hardening गाइड (नए टैब में खुलता है) कहती है कि WordPress और प्लगइन अपडेट रखें, इस्तेमाल न होने वाले प्लगइन डिलीट करें, और अपने होस्ट से पूछें कि वे सुरक्षा के लिए क्या सावधानियाँ बरतते हैं।

यह पेनिट्रेशन टेस्ट क्यों नहीं है?

पेनिट्रेशन टेस्ट में सक्रिय रूप से हमले करने की कोशिश की जाती है; पैसिव चेक सिर्फ़ देखते हैं।

NIST SP 800-115 पेनिट्रेशन टेस्टिंग को ऐसी सिक्योरिटी टेस्टिंग के रूप में परिभाषित करता है जिसमें जाँचकर्ता असली हमलों की नकल करके किसी सिस्टम के सिक्योरिटी फ़ीचर्स से बचकर निकलने के तरीके खोजते हैं (NIST glossary (नए टैब में खुलता है))। पैसिव चेक प्लगइन की सर्वर-साइड कमियाँ, कमज़ोर या दोबारा इस्तेमाल किए गए एडमिन पासवर्ड, गायब टू-फ़ैक्टर ऑथेंटिकेशन, टूटा हुआ एक्सेस कंट्रोल या ऐसा कमज़ोर कोड नहीं देख सकते जो पेज सोर्स में कभी दिखता ही नहीं। इन्हें एक बेसलाइन के रूप में इस्तेमाल करें, जिसे आप कभी भी दोहरा सकते हैं। ज़्यादा गहरे भरोसे के लिए लिखित स्कोप के साथ पेनिट्रेशन टेस्ट करवाएँ, उन्हीं सिस्टम पर जो आपके हैं या जिन्हें टेस्ट करने की आपको अनुमति है।

एक मुफ़्त स्कैन आपके स्टोर की पहली जाँच करता है। वेबसाइट सुरक्षा रिपोर्ट इस लेख की पैसिव जाँचों को कवर करती है, TLS और रीडायरेक्ट से लेकर हेडर, कुकीज़, मिक्स्ड कंटेंट, पुरानी लाइब्रेरी, security.txt और DMARC तक, और हर नतीजे के लिए सुधार बताती है। किसी भी पैसिव समीक्षा की तरह, यह गारंटी नहीं दे सकती कि स्टोर सुरक्षित है।

अक्सर पूछे जाने वाले प्रश्न

क्या पैसिव सिक्योरिटी चेक से मेरे स्टोर को कोई ख़तरा है?

किसी सामान्य विज़िट से ज़्यादा नहीं। ये वही पब्लिक पेज और DNS रिकॉर्ड माँगते हैं जो कोई भी ब्राउज़र या मेल सर्वर माँगता है, और ये न लॉगिन करने की कोशिश करते हैं, न अटैक पेलोड भेजते हैं।

क्या Shopify पर सिक्योरिटी हेडर जोड़े जा सकते हैं?

स्टोरफ़्रंट के रिस्पॉन्स हेडर Shopify के सर्वर से आते हैं, इसलिए अगर आपको जिस हेडर की ज़रूरत है वह गायब है, तो Shopify Support से संपर्क करें। आपकी थीम में CSP <meta> टैग कुछ डायरेक्टिव जोड़ सकता है, लेकिन MDN बताता है कि frame-ancestors <meta> में सपोर्टेड नहीं है।

क्या पुराने jQuery वर्ज़न का मतलब है कि मेरा स्टोर हैक हो चुका है?

नहीं। इसका मतलब है कि ज्ञात कमज़ोरियों वाला कोड लोड हो रहा है, जिससे जोखिम बढ़ता है, अगर साइट प्रभावित मेथड को अविश्वसनीय HTML देती है। इसे अपडेट करें, या वह थीम या प्लगइन हटा दें जो इसे लोड करता है।

अब कोई TLS सर्टिफ़िकेट कितने समय तक वैध रह सकता है?

15 मार्च 2026 से जारी सार्वजनिक रूप से भरोसेमंद सर्टिफ़िकेट ज़्यादा से ज़्यादा 200 दिन तक वैध रह सकते हैं। 15 मार्च 2027 से यह सीमा 100 दिन और 15 मार्च 2029 से 47 दिन हो जाएगी।

क्या security.txt फ़ाइल ज़रूरी है?

RFC 9116 एक Informational RFC है, इसलिए इस स्टैंडर्ड के तहत फ़ाइल पब्लिश करना स्वैच्छिक है। इसे पब्लिश करना आसान और सस्ता है, और इससे रिसर्चर्स को आप तक पहुँचने का साफ़ रास्ता मिलता है।

क्या साफ़ पैसिव स्कैन का मतलब है कि मेरा स्टोर सुरक्षित है?

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

स्रोत

• Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, version 2.3.1 (नए टैब में खुलता है), CA/Browser Forum, 4 अक्टूबर 2026
• Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (नए टैब में खुलता है), CA/Browser Forum, 11 अप्रैल 2025
• Strict-Transport-Security (नए टैब में खुलता है), MDN Web Docs, आख़िरी बदलाव 11 सितंबर 2026
• CSP: frame-ancestors (नए टैब में खुलता है), MDN Web Docs, आख़िरी बदलाव 27 अगस्त 2026
• X-Content-Type-Options (नए टैब में खुलता है), MDN Web Docs, आख़िरी बदलाव 17 मार्च 2026
• Using HTTP cookies (नए टैब में खुलता है), MDN Web Docs, आख़िरी बदलाव 17 सितंबर 2026
• Mixed content (नए टैब में खुलता है), MDN Web Docs, आख़िरी बदलाव 15 अगस्त 2026
• HTTP Security Response Headers Cheat Sheet (नए टैब में खुलता है), OWASP Cheat Sheet Series, 22 अक्टूबर 2026 को देखा गया
• CVE-2020-11022 (नए टैब में खुलता है), NIST National Vulnerability Database, 29 अप्रैल 2020 को प्रकाशित
• CVE-2020-11023 (नए टैब में खुलता है), NIST National Vulnerability Database, 29 अप्रैल 2020 को प्रकाशित
• CVE-2019-11358 (नए टैब में खुलता है), NIST National Vulnerability Database, 20 अप्रैल 2019 को प्रकाशित
• .jquery (नए टैब में खुलता है), jQuery API Documentation, 22 अक्टूबर 2026 को देखा गया
• Updating core jQuery to version 3, part 2 (नए टैब में खुलता है), Make WordPress Core, 5 नवंबर 2020
• RFC 9116: A File Format to Aid in Security Vulnerability Disclosure (नए टैब में खुलता है), IETF, अप्रैल 2022
• RFC 9989: Domain-Based Message Authentication, Reporting, and Conformance (DMARC) (नए टैब में खुलता है), IETF, मई 2026
• Enabling secure connections to your Shopify store (नए टैब में खुलता है), Shopify Help Center, 22 अक्टूबर 2026 को देखा गया
• Security (नए टैब में खुलता है), Shopify, 22 अक्टूबर 2026 को देखा गया
• Hardening WordPress (नए टैब में खुलता है), WordPress Developer Resources, 22 अक्टूबर 2026 को देखा गया
• Penetration testing (glossary) (नए टैब में खुलता है), NIST Computer Security Resource Center, NIST SP 800-115 (सितंबर 2008) के हवाले से, 22 अक्टूबर 2026 को देखा गया