CDS · वेबसाइट सुरक्षा मार्गदर्शिका · 2026

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

मुख्य बात: HTTPS सुरक्षा की एक आवश्यक परत है, पूरी सुरक्षा जाँच का विकल्प नहीं।

HTTPS वास्तव में क्या देता है?

डेटा एन्क्रिप्शन

TLS सही तरीके से स्थापित होने पर HTTPS, क्लाइंट और HTTPS endpoint के बीच HTTP ट्रैफ़िक को एन्क्रिप्ट करता है।

सर्वर की पहचान

सर्टिफ़िकेट सत्यापन यह जाँचने में मदद करता है कि सर्टिफ़िकेट अनुरोधित hostname के लिए है और भरोसेमंद issuer से जुड़ा है।

यात्रा के दौरान अखंडता

TLS डेटा के एक endpoint से दूसरे तक जाते समय अनधिकृत बदलाव रोकने में मदद करता है।

इनसे यह साबित नहीं होता कि application code, server configuration, administrator accounts, plugins या third-party scripts सुरक्षित हैं।

HTTPS अपने आप किन चीज़ों से सुरक्षा नहीं देता?

  • कमज़ोर application code या असुरक्षित plugins।
  • कमज़ोर पासवर्ड, समझौता किए गए administrator accounts या खराब access controls।
  • पुराना सॉफ़्टवेयर या असुरक्षित server configuration।
  • दुर्भावनापूर्ण या समझौता किए गए third-party scripts और dependencies।
  • गलत cookie/session settings या CSP जैसी अपर्याप्त browser-security policy।
  • हर पेज और resource के सुरक्षित रूप से लोड होने की गारंटी।
  • यह गारंटी कि वेबसाइट कभी compromise नहीं होगी या penetration test की ज़रूरत समाप्त हो जाती है।

HTTPS के साथ की जाने वाली सात जाँचें

  1. सर्टिफ़िकेट और hostname

    जाँचें कि सर्टिफ़िकेट सही hostname के लिए वैध है, उसकी अवधि समाप्त नहीं हुई और ब्राउज़र सत्यापन सफल है। सर्टिफ़िकेट transport/authentication control है, पूरी सुरक्षा जाँच नहीं।

  2. HTTP से HTTPS पर भेजना

    HTTP URL खोलकर देखें। जहाँ HTTP की ज़रूरत न हो, वेबसाइट को सही HTTPS URL पर भेजना चाहिए। दोनों प्रोटोकॉल अलग-अलग उपलब्ध होना समीक्षा का कारण है, compromise का प्रमाण नहीं।

  3. HSTS

    जाँचें कि Strict-Transport-Security deployment के अनुसार कॉन्फ़िगर है। HSTS भविष्य के कनेक्शनों में ब्राउज़र को HTTPS प्राथमिकता देने के लिए कह सकता है; यह application security का विकल्प नहीं।

  4. Mixed content

    जाँचें कि HTTPS पेज असुरक्षित HTTP से resources तो नहीं माँग रहा। HTTPS सक्रिय होने पर भी ऐसे references ठीक करने पड़ सकते हैं।

  5. Security headers

    जहाँ उपयुक्त हो, CSP, X-Content-Type-Options, framing protections और Referrer-Policy की समीक्षा करें। ये TLS के पूरक controls हैं।

  6. Cookies और sessions

    उचित Secure, HttpOnly और SameSite attributes देखें। सही settings application design पर निर्भर करती हैं; किसी एक attribute का न होना अपने आप session takeover साबित नहीं करता।

  7. Application और technology maintenance

    जहाँ दिखे वहाँ CMS/framework/runtime components पहचानें, फिर supported versions, patches, access controls और application-level security जाँचें। HTTPS असुरक्षित application logic या vulnerable component ठीक नहीं करता।

सितंबर 2026 की समीक्षा में क्या देखा गया?

CDS/AuthSetu की 92 अधिकृत public-facing targets की समीक्षा में normalized V5 dataset ने 50 targets (54.3%) पर HSTS और 45 (48.9%) पर CSP दर्ज किया। ये आँकड़े केवल उसी dataset के हैं; सभी छोटे व्यवसायों की वेबसाइटों का प्रतिनिधि अनुमान नहीं हैं।

कुछ मामलों में HTTPS सक्रिय था, लेकिन security headers, technology disclosure या HTTP/HTTPS handling जैसे hardening सवाल बाकी थे। प्रमाण configuration review का समर्थन करते थे, compromise के दावे का नहीं।

आम धारणाएँ और सही अर्थ

आम धारणाज़्यादा सटीक अर्थ
“SSL है, इसलिए वेबसाइट सुरक्षित है।”TLS/HTTPS सुरक्षा की एक परत है।
“ब्राउज़र चेतावनी नहीं देता, इसलिए कोई समस्या नहीं।”Transport status पूरी application security जाँच नहीं है।
“HSTS नहीं है, इसलिए वेबसाइट hack हो गई।”मज़बूत प्रमाण न हो तो यह configuration संबंधी observation है।
“सर्टिफ़िकेट वैध है, इसलिए पूरा सर्वर भरोसेमंद है।”सर्टिफ़िकेट पूरी application या व्यवसाय को validate नहीं करता।
“HTTPS है, इसलिए ग्राहक डेटा सुरक्षित है।”सुरक्षित transport, storage, authorization या application logic की गारंटी नहीं देता।

ज़िम्मेदार निष्कर्ष कैसा होना चाहिए?

“HTTPS सक्रिय है और सर्टिफ़िकेट सत्यापन सफल है। आगे transport enforcement, HSTS, mixed-content व्यवहार, browser-security headers, cookie/session controls और underlying application stack की समीक्षा होनी चाहिए।”

सिर्फ ताले के निशान से वेबसाइट को असुरक्षित घोषित करने के बजाय यह निष्कर्ष बेहतर है, क्योंकि हर बिंदु को जाँचा जा सकता है।

गहरी जाँच कब ज़रूरी है?

यदि वेबसाइट पर login, payments, ग्राहक रिकॉर्ड, संवेदनशील forms, आंतरिक workflows या privileged administration हैं, तो passive HTTPS/header check को शुरुआती कदम मानें। जोखिम और स्पष्ट अनुमति के आधार पर authenticated assessment, vulnerability validation, secure-code review या penetration testing उचित हो सकती है।

संबंधित लेख

अपनी वेबसाइट की सुरक्षा स्थिति को बेहतर समझना चाहते हैं?

CDS वेबसाइट configuration की समीक्षा करके देखे गए निष्कर्षों को व्यावहारिक व्यावसायिक भाषा में समझाने में मदद कर सकता है। जाँच की गहराई जोखिम और सहमत authorization scope के अनुसार तय होनी चाहिए।

Chaitanya Digital Solutions से संपर्क करें

दायरा और सीमाएँ: यह लेख defensive security methodology और सितंबर 2026 की अधिकृत passive review पर आधारित है। Automated observations कुछ controls पहचानने में चूक सकते हैं और compromise सिद्ध नहीं करते। किसी विशिष्ट target पर दावा करने से पहले live configuration दोबारा जाँचें। कोई unauthorized access या exploitation निहित नहीं है।